Special schedulers, one CPU only kernel, one only userland
John Baldwin
jhb at FreeBSD.org
Thu Aug 11 15:36:17 GMT 2005
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 at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-arch
mailing list