Date: Wed, 24 May 2000 19:03:55 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Chuck Paterson <cp@bsdi.com> Cc: arch@FreeBSD.ORG Subject: Re: Short summary Message-ID: <200005250203.TAA78162@apollo.backplane.com> References: <200005250103.TAA15470@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: What is being proposed here is a major kernel architectural
:change. The locking provided by SPLS in the traditional BSD kernel goes away
:and is replaced by mutexs. This model is very different. Interrupts
:do not in general get blocked. When interrupt service code needs
:access to some piece of data which is actively being modified by
:what is traditionally thought of as the "top half" the interrupt
:thread will block at that point. The finer grained the locking the
:less chance of a collision, but the number of locking operation
:goes up and a price has to be paid.
:...
:Chuck
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005250203.TAA78162>