From owner-freebsd-arch Thu May 25 9:35:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C90AC37C97F for ; Thu, 25 May 2000 09:35:15 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA83014; Thu, 25 May 2000 09:35:11 -0700 (PDT) (envelope-from dillon) Date: Thu, 25 May 2000 09:35:11 -0700 (PDT) From: Matthew Dillon Message-Id: <200005251635.JAA83014@apollo.backplane.com> To: Chuck Paterson Cc: arch@freebsd.org Subject: Re: Short summary References: <200005250241.UAA16669@berserker.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : :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? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message