Date: Tue, 16 Aug 2005 06:58:43 -0600 From: Scott Long <scottl@samsco.org> To: Luigi Rizzo <rizzo@icir.org> Cc: frank@exit.com, Andre Oppermann <andre@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Special schedulers, one CPU only kernel, one only userland Message-ID: <4301E303.9060101@samsco.org> In-Reply-To: <20050816051231.D66550@xorpc.icir.org> References: <42F9ECF2.8080809@freebsd.org> <200508101638.27087.jhb@FreeBSD.org> <42FA6E0E.4070205@samsco.org> <200508111121.46546.jhb@FreeBSD.org> <20050816051231.D66550@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > reading this thread, and at times looking at some of the kernel code, > with plenty of places where you have to drop a lock that you > already have, do some small thing and then reacquire the lock itself, > makes me wonder if we don't need a better mechanism/abtraction for > this kind of programming. > > In a way, this seems similar to the handling of interrupts: > if we want a thread to be interrupted we don't check for interrupts > (and save and restore state) explicitly at every instruction, but > rely on the processor doing the right thing for us. > > I am sorry i cannot formulate the analogy in a clearer way > (if i could i would probably have a design to address this problem :( ) > > cheers > luigi > You're saying that you would like a system where a thread that wants a lock can ask another thread that has the lock to temporarily give it up and go to sleep? Scott > On Thu, Aug 11, 2005 at 11:21:45AM -0400, John Baldwin wrote: > >>On Wednesday 10 August 2005 05:13 pm, Scott Long wrote: >> >>>John Baldwin wrote: >>> >>>>On Wednesday 10 August 2005 04:10 pm, Frank Mayhar wrote: >>>> >>>>>On Wed, 2005-08-10 at 09:11 -0400, John Baldwin wrote: >>>>> >>>>>>I think this is the model that BSD/OS employed >>>>>>for SMP in its 4.x series before they did their version of SMPng. >>>>> >>>>>I didn't grunge around in the scheduler (much), but as far as I'm aware >>>>>BSD/OS 4.x used the Big Giant Lock mechanism just as FreeBSD did, and >>>>>for the same reason. >>>> >>>>I believe that at some point during the 4.x series they added a scheduler >>>>lock that covered just enough to allow threads that weren't asleep in the >>>>kernel to be switched to without require the big giant lock and that it >>>>was a pretty decent performance win over the earlier single BGL ala >>>>FreeBSD 4.x. >>> >>>So when a syscall is made on an AP, does it get serviced on the same AP >>>(assuming that the lock is available and no sleeping is needed), or does >>>it get serviced my the BSP? Where kernel threads explicitely pinned to >>>the BSP? Was the APIC explicitely programmed to deliver only to the >>>BSP? >> >>I think the AP would block on the BGL in the stuff BSD/OS did, but Schimmel >>points out that that can be non-optimal (SMP in 4.x was basically about the >>worst possible idea according to Schimmel). A better implementation of >>master/slave is for all syscalls, traps, and interrupts to run only on the >>BSP and have the APs just run in userland. I.e. they could take over a >>thread that had made it to userret (when you get to userret, you would mark >>the thread as a user thread somwhow) and when a thread running on an AP >>wanted to enter the kernel (syscall or trap), it would have to stick the >>thread on the runqueue for the BSP and go look for another user thread. >> >>-- >>John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ >>"Power Users Use the Power to Serve" = http://www.FreeBSD.org >>_______________________________________________ >>freebsd-arch@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-arch >>To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4301E303.9060101>