Date: Tue, 24 Oct 2000 07:15:34 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jasone@canonware.com (Jason Evans) Cc: seth@pengar.com (Seth Leigh), smp@FreeBSD.ORG Subject: Re: SA project (was Re: SMP project status) Message-ID: <200010240715.AAA10142@usr01.primenet.com> In-Reply-To: <20001023232717.T3993@canonware.com> from "Jason Evans" at Oct 23, 2000 11:27:17 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> On Tue, Oct 24, 2000 at 01:31:47AM -0700, Seth Leigh wrote: > > At 06:23 PM 10/23/2000 -0700, Jason Evans wrote: > > >Work is ramping up on scheduler activations, which will allow scaling of > > >threaded applications in proportion to the number of processors. > > > > What exactly does this mean? > > > > Are we going to have something like the Solaris LWP, and schedule those > > instead of processes? Basically, what will be the nature of the FreeBSD > > thread, in terms of kernel schedulable entities? > > See http://people.freebsd.org/~jasone/refs/p95-anderson.pdf for a > description of scheduler activations. In laymans terms, it means that FreeBSDs threading system will end up being vastly superior to everything but high end commercial UNIX implementations, and superior to a number of those, as well. Specifically, it means that a multithreaded process will not incur the context switch overhead that one normally sees as a result of a blocking call on systems where user space threads are implemented using kernel threads (e.g. Linux, Solaris, NT, Windows 95/98/2000, and any SVR4.0.2 or later derived system). In older designs, using kernel threads as backing objects for user space (process level) threads, when a blocking call is made, the kernel goes into the scheduler, and picks another runnable object to schedule; often this is not something in the same process context as the one making the blocking call, so the promise of threading overhead saving the cost of a full context switch is almost never realized on any system with a non-manufactured workload. A scheduler activation, on the other hand, can reactivate in the specific process (picking another thread from the thread group), so long as there is quantum remaining, and thus actually deliver on the promise of reduced context switch overhead. A side benefit is that cache coherency is also maintained, and there is a reduced interprocessor arbitration overhead. The only approach that's significantly better than activations is a full on async call gate, since it reduces the amount of costly protection domain crossing even further; this can be improved to a larger extent, as well, by dual-mapping pages between user and kernel space to use for communicating completion events. It would have significantly reduced the complexity of the kernel and user space scheduler code to have utilized an async call gate approach, but there would have been a significant cost in terms of binary compatability (it would mean that the standard blocking POSIX calls would have to be implemented as library routines that did an explicit wait for the async call completion event). Binary backward compatability would have meant keeping the existing call structure in place, in parallel, which is a heavy maintenance burden, though not necessarily a long term one. > > Won't this require a whole new thread library implementation? If so, who > > is leading that effort? > > The kernel modifications and userland work aren't being treated as separate > projects, but they probably will not be implemented in parallel. Large > portions of libc_r should be useable. > > As for someone leading the effort, there isn't a formal leader. I'm the > instigator, and Dan Eischen and David O'Brien have expressed interest in > working together on it. Archie and Julian have also expressed interest off and on, as have others. It was perhaps the biggest single turnout that we have ever had at a FreeBSD user group meeting (BAFUG/BABUG). Perhaps the biggest pain is the default signal behaviour, which no longer results in system call restart. This means that the signal code must self-mask anything that it wants to pretend is a system call, for every wrapping library routine. POSIX really screwed us over on that account, kind of like what they did to locks when you close one of several file handles to the same file. As Jason has noted, most of this code can be reused out of the existing lib_r, with few or no changes, so that's not a pain that will be returning to haunt us. Most, if not all, of the user space work will be in the user space scheduler, dealing with what to do when an activation occurs. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010240715.AAA10142>