From owner-freebsd-arch Sat May 27 4: 2:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id A0BA337B8E3 for ; Sat, 27 May 2000 04:02:18 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 12veMC-000GEr-0B; Sat, 27 May 2000 11:02:17 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id MAA69578; Sat, 27 May 2000 12:09:19 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sat, 27 May 2000 12:07:47 +0100 (BST) From: Doug Rabson To: Matthew Dillon Cc: Chuck Paterson , arch@freebsd.org Subject: Re: Short summary In-Reply-To: <200005251635.JAA83014@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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