Re: Special schedulers, one CPU only kernel, one only userland

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 08/11/05

  • Next message: m.ehinger_at_ltur.de: "sysctl_proc calls handler twice" 
    To: Scott Long <scottl@samsco.org>
Date: Thu, 11 Aug 2005 11:21:45 -0400

    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"
  • Next message: m.ehinger_at_ltur.de: "sysctl_proc calls handler twice"

    Relevant Pages

    • Re: Special schedulers, one CPU only kernel, one only userland
      ... already have, do some small thing and then reacquire the lock itself, ... this seems similar to the handling of interrupts: ... >> it get serviced my the BSP? ... Where kernel threads explicitely pinned to ...
      (freebsd-arch)
    • [patch 00/10] PI-futex: -V1
      ... We are pleased to announce "lightweight userspace priority inheritance" ... No registration, no extra kernel ... only a single owner may own a lock (i.e. no ... Priority Inheritance - why, oh why??? ...
      (Linux-Kernel)
    • Re: CFR: New NFS Lock Manager
      ... It also includes minor fixes to support 64bit architectures and RELENG_7. ... Lock Manager which runs in kernel mode and uses the normal local locking infrastructure for its state. ... A single thread should be sufficient for the NLM since it should rarely block in normal operation. ...
      (freebsd-current)
    • [patch 3/6] lightweight robust futexes: docs
      ... +The robust futex ABI ... for kernel assist of cleanup of held locks on task exit. ... will attempt to process both lists on each task ... pointer to a single linked list of 'lock entries', one per lock, ...
      (Linux-Kernel)
    • Re: FreeBSD 7.0 crashed when running super-smack upon PostgreSQL
      ... Is there any chance I can get remote access to a box holding the synchronized kernel, kernel debugging symbols, source code, and core dump? ... It sounds like TCP in a user thread is stumbling over a violation of system invariants (don't sleep while holding a mutex) performed by another thread. ... We need to track down the original thread and figure out why it's sleeping while holding that lock -- perhaps it's a user thread performing a copyin/copyout holding the lock, or perhaps an ithread or other software interrupt thread acquiring a lock of an inappropriate type while holding the lock. ... kgdb has its own thread ID scheme so you'll need to use info threads to track down the right kgdb thread id before you can select the identified kernel thread/process. ...
      (freebsd-stable)