From owner-freebsd-current  Mon Jun 19 18:12:45 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id EACBC37B636
	for <current@FreeBSD.ORG>; Mon, 19 Jun 2000 18:12:41 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id SAA82090;
	Mon, 19 Jun 2000 18:12:40 -0700 (PDT)
	(envelope-from dillon)
Date: Mon, 19 Jun 2000 18:12:40 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200006200112.SAA82090@apollo.backplane.com>
To: Jason Evans <jasone@canonware.com>
Cc: current@FreeBSD.ORG
Subject: Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
References: <20000619115330.D79318@blitz.canonware.com> <200006200034.RAA81825@apollo.backplane.com> <20000619180113.G79318@blitz.canonware.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:On this page, you say:
:
:  The algorithms described on this page are essentially the BSDI algorithms
:  plus accomodations we disussed at the Yahoo SMP meeting. However, I did
:  not do a direct port. I did a from-scratch rewrite because, simply put,
:  it was easier for me. The variables are named differently but I attempt
:  to follow the same API. All the work is subject to change... the point is
:  to make it work first, then clean it up later.
:
:Does this include the locking primitives?  In the case of the locking
:primitives, there is functionality that we definitely need, such as the
:witness code, and it probably would save effort to use the BSD/OS code.
:I'm guessing that you are actually using the BSD/OS code in this case; I'm
:just looking for clarification.
:
:Thanks,
:Jason

    The API is very similar, and when I clean it up it should be possible
    to make it exactly the same, but SPL/CPL/INTERRUPT considerations 
    make using the BSDI code verbatim impossible.

    Basically I rewrote the core mutex code but I used *everything* that
    was discussed at the meeting in the implementation, so all the features
    that we need are there.  Spin locks, blocking locks, Giant lock
    save/restore integrated into the scheduler, quick-attempt in an
    inline then a call to a real procedure if it fails, using the low 2
    bits of the mutex lock field to implement a 'held' bit and a 'contested'
    bit (which works really wonderfully, I might add!  I would never have
    thought of doing things that way myself!).

    I am trying to keep it close enough that we can add the witness code
    in, but before I do that I want to get the system semi-stable.
    In some respects it's actually easier for us with FreeBSD
    because we are keeping the spl*() system intact for a while.

    The witness code is going to be critical for the unwinding work (moving
    things out of the Giant mutex and into their own mutexes).  It isn't
    critical for this first stage which basically just puts everything
    under the Giant lock and doesn't *have* any other mutexes beyond 
    SchedMutex and GiantMutex.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message