Date: Sun, 22 Sep 2002 20:29:29 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Bill Huey (Hui)" <billh@gnuppy.monkey.org> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com>, freebsd-arch@FreeBSD.ORG Subject: Re: New Linux threading model Message-ID: <3D8E8A99.CED8BAD0@mindspring.com> References: <Pine.GSO.4.10.10209200002280.2162-100000@pcnet1.pcnet.com> <3D8B62DB.C27B7E07@mindspring.com> <20020923014729.GA3362@gnuppy.monkey.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"Bill Huey (Hui)" wrote: > On Fri, Sep 20, 2002 at 11:03:07AM -0700, Terry Lambert wrote: > > By going to 1:1, they dodge this issue; but in so doing, they > > increase threads overhead to that of processes: threads become > > a mechanism for sharing some resources: the moral equivalent of > > the old rfork()/sfork() system calls for heap and descriptor > > space sharing, with seperate stacks. > > Conceptually this is definitely the case, but this says otherwise > for the particular operations they outline in this email: > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.2/1581.html > > Not sure what to think about this... The first set were the microbenchmarks I was talking about being unrepresentative of a system load where the test processes were actually competing with other processes, because they were run in a single process on an otherwise quiescent system. The second set match the overload behaviour I suggested that should be expected under overload conditions, where the overall performance degrades to (effectively) non-affinity performance. They noted these as issues, themselves, near the end of the email, without providing a real analysis as to why: | The results of this test series are: | | - - LinuxThreads indeed had several problems | | - - NGPT indeed run much faster (twice the performance) | | - - NPTL runs four times faster than NGPT in a benchmark which by all | means should favor an M-on-N implementation. This still misses the multiple benchmark processes running multithreaded simultaneously, which I think would demonstrate a third stair-step in performance. Note that there is probably a fourth, which would be missed, unless the test programs were copied to duplicate program inages, rather than running out of the same executable image file, to ensure against page sharing among the competing images. I'd still like to see *that* benchmark, because I believe it would be worst-case for the scheduler design, but common enough with, e.g., a mail server like sendmail, qmail, or postfix, or with Samba. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D8E8A99.CED8BAD0>