Date: Wed, 24 May 2000 20:41:00 -0600 From: Chuck Paterson <cp@bsdi.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@freebsd.org Subject: Re: Short summary Message-ID: <200005250241.UAA16669@berserker.bsdi.com>
next in thread | raw e-mail | index | archive | help
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
<dillon@backplane.com>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005250241.UAA16669>