Date: Sat, 27 May 2000 12:07:47 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Chuck Paterson <cp@bsdi.com>, arch@freebsd.org Subject: Re: Short summary Message-ID: <Pine.BSF.4.21.0005271205400.73457-100000@salmon.nlsystems.com> In-Reply-To: <200005251635.JAA83014@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 25 May 2000, Matthew Dillon wrote: > > : > : > :What BSD/OS did, and I the only way I understand to solve the > :problem is sort of the same as your collapse into a single > :mutex, except we collapsed even more. > : > :This is the short version: > :We created a single lock "Giant". All the paths into the kernel > :got Giant and as they left released it. We also made sleep and > :tsleep release Giant, and re-acquire it when a process starts to > :run. At that point we turned SPLS off. There are at this point no > :interrupts in the kernel, but who cares it was just used to make > :progress. The amazing thing was that the system didn't "feel" bad. > :I later learned that many/most/all Cray models run without interrupts > :in the kernel. Some place along here we added the extra argument > :to sleep/tsleep, maybe first maybe now. We were then able to start > :pulling code out from under Giant. We build facilities to do the > :"right" thing for safe and unsafe drivers through dev switch and > :interrupt service. > : > :Chuck > > I think this will work to get the ball rolling. We can simply > 'cli' in the MP lock code and 'sti' in the MP last-unlock code > ( i386/i386/mplock.s ). Then we can turn the spl*() calls into > NOPs and do the (relatively trivial) fixup to the scheduler. > Actually, I don't think we would have to touch the scheduler at all > for this step, it already releases the MP lock and it already supports > scheduling supervisor contexts to multiple cpu's. (In fact, we > already support lockless system calls even though only a few trivial > calls do it at the moment!). > > The next step would be to implement interrupt threads and simply > allow them to be scheduled by the scheduler holding the MP lock. > > After the interrupts are all threaded, we can start removing the MP > lock and switching subsystems over to use mutexes. > > What do you think? I think this is a workable plan. If we can get to the stage of just being able to sleep instead of spin on the giant lock, we ought to see a performance improvement since cpus not inside the kernel can then be running user-space processes more often. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0005271205400.73457-100000>