From owner-freebsd-smp Tue Oct 24 6:41:49 2000 Delivered-To: freebsd-smp@freebsd.org Received: from gtei2.bellatlantic.net (gtei2.bellatlantic.net [199.45.39.161]) by hub.freebsd.org (Postfix) with ESMTP id F16AB37B479 for ; Tue, 24 Oct 2000 06:41:45 -0700 (PDT) Received: from seth-f1pgytg8r3 (client-64-223-145-91.bellatlantic.net [64.223.145.91]) by gtei2.bellatlantic.net (8.9.1/8.9.1) with SMTP id JAA13077; Tue, 24 Oct 2000 09:37:09 -0400 (EDT) Message-Id: <3.0.6.32.20001024094101.00c4d798@hobbiton.shire.net> X-Sender: seth-pc@hobbiton.shire.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 24 Oct 2000 09:41:01 -0700 To: Terry Lambert , jasone@canonware.com (Jason Evans) From: Seth Leigh Subject: Re: SA project (was Re: SMP project status) Cc: smp@FreeBSD.ORG In-Reply-To: <200010240715.AAA10142@usr01.primenet.com> References: <20001023232717.T3993@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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