From owner-freebsd-arch Wed May 24 19:41: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 7FF1737B83B for ; Wed, 24 May 2000 19:41:04 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@[127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id UAA16669; Wed, 24 May 2000 20:41:01 -0600 (MDT) Message-Id: <200005250241.UAA16669@berserker.bsdi.com> To: Matthew Dillon Cc: arch@freebsd.org Subject: Re: Short summary From: Chuck Paterson Date: Wed, 24 May 2000 20:41:00 -0600 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 ----- Begin Included Message ----- We've discussed SMP evolution on and off over the last year or two, and I think everyone will agree that the data-centric mid-range granularity mutex model is the best way to go. The one problem with this concept is that there is no easy migration path getting from SPL ops to Mutex ops, because an SPL op currently involves a bitmask of several interrupts rather then a single interrupt. Thus the SPL ops would translate into several mutexes rather then a single mutex and wind up being *very* expensive for the period of time it takes us to then move onto the next step (collapsing them into single mutexes again). We were looking for an easier migration path in order to try to keep the kernel runnable for the month or two (or longer) it would require to get everything straightened out. At this point in time I've thrown up my hands and am now willing to take this intermediate step just to get the ball rolling, under the assumption that we can collapse the mutexes together in fairly short order once we get them working in the first place. Another possibility is to simply collapse all the spl*()'s into a single mutex temporarily and then slowly move code sections into using their own data-mutexes, which is easier to do but has obvious interrupt performance issues. Do you have any thoughts on how to deal with this problem? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message ----- End Included Message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message