Date: Mon, 19 Jun 2000 18:12:40 -0700 (PDT) From: Matthew Dillon <dillon@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) Message-ID: <200006200112.SAA82090@apollo.backplane.com> References: <20000619115330.D79318@blitz.canonware.com> <200006200034.RAA81825@apollo.backplane.com> <20000619180113.G79318@blitz.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006200112.SAA82090>