Date: Wed, 02 Apr 2003 13:11:24 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: Jeff Roberson <jroberson@chesapeake.net> Subject: Re: libthr and 1:1 threading. Message-ID: <3E8B51FC.63F8BE55@mindspring.com> References: <Pine.NEB.3.96L.1030402093336.34476D-100000@fledge.watson.org> <3E8B03E6.36871704@mindspring.com> <20030402154716.GE790@starjuice.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Sheldon Hearn wrote: > On (2003/04/02 07:38), Terry Lambert wrote: > > Is the disk I/O really that big of an issue? All writes will > > be on underlying non-blocking descriptors; I guess you are > > saying that the interleaved I/O is more important, further > > down the system call interface than the top, and this becomes > > an issue? > > Dude, you should really try this stuff for yourself before naysaying > performance improvements on principle. It's actually quite impressive > for desktop users (at least). I have. I can't tell if it's the scheduler quantums or the concurrency from the threads. I'm going to have to specifically write code to find out, and it may take me a while to do it; I have to figure out a way to put the user space stalls back for descriptor accesses, so the tests run on an equal footing. Right now, I have to decide whether it's worth the hassle of combining the libc_r and libthr code to do that, or if I should just drop it, and let you guys turn FreeBSD's threads into Linux. PS: My gut tells me it's not the concurrency; the resolver is the bottleneck for things like Mozilla (IMO), and it still has to stall concurrency. PPS: I'll get back to you after I size the job, and decide. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E8B51FC.63F8BE55>