Date: Tue, 24 Oct 2000 09:41:01 -0700 From: Seth Leigh <seth@pengar.com> To: Terry Lambert <tlambert@primenet.com>, jasone@canonware.com (Jason Evans) Cc: smp@FreeBSD.ORG Subject: Re: SA project (was Re: SMP project status) Message-ID: <3.0.6.32.20001024094101.00c4d798@hobbiton.shire.net> In-Reply-To: <200010240715.AAA10142@usr01.primenet.com> References: <20001023232717.T3993@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 07:15 AM 10/24/2000 +0000, Terry Lambert wrote: >> 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. This may seem petty, but if we always use the whole quantum, won't this have the effect of driving down the priority of any multi-threaded application with respect to single-threaded apps? You will pardon me if I ask dumb questions. After dabbling and reading about it for a long time, I have finally started working on my first major multi-threaded application, and so I am thinking a lot about them but I am not necessarily a guru. Additionally, I aspire someday to being a kernal guy, so I want to learn how these things work. >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?3.0.6.32.20001024094101.00c4d798>