Date: Tue, 16 Aug 2005 05:12:31 -0700 From: Luigi Rizzo <rizzo@icir.org> To: John Baldwin <jhb@freebsd.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: <20050816051231.D66550@xorpc.icir.org> In-Reply-To: <200508111121.46546.jhb@FreeBSD.org>; from jhb@freebsd.org on Thu, Aug 11, 2005 at 11:21:45AM -0400 References: <42F9ECF2.8080809@freebsd.org> <200508101638.27087.jhb@FreeBSD.org> <42FA6E0E.4070205@samsco.org> <200508111121.46546.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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?20050816051231.D66550>