From owner-freebsd-arch  Wed May 24 19: 4: 2 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 90DE037B6CC
	for <arch@FreeBSD.ORG>; Wed, 24 May 2000 19:03:59 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id TAA78162;
	Wed, 24 May 2000 19:03:55 -0700 (PDT)
	(envelope-from dillon)
Date: Wed, 24 May 2000 19:03:55 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200005250203.TAA78162@apollo.backplane.com>
To: Chuck Paterson <cp@bsdi.com>
Cc: arch@FreeBSD.ORG
Subject: Re: Short summary
References:  <200005250103.TAA15470@berserker.bsdi.com>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:	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