Date: Sun, 27 Jun 1999 14:34:40 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-smp@FreeBSD.ORG Subject: Re: high-efficiency SMP locks - submission for review Message-ID: <Pine.BSF.3.95.990627142319.8298I-100000@current1.whistle.com> In-Reply-To: <199906272024.NAA15634@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 27 Jun 1999, Matthew Dillon wrote:
> I would like to know what the SMP gurus think of this code. I have
> not posted the complete patch, but have included the meat of the code.
> I am interested in comments relating to the implementation & performance
> aspects of the code. I would also appreciate it if an inline assembly
> expert could look at my inline assembly. I have tested it well and
> I believe it to be correct, but I don't write much inline assembly so...
>
> This code is designed to implement extremely low overhead SMP-compatible
> locks. It will probably be used instead of lockmgr() locks for the
> buffer cache, and I hope to use it as a basis to replace lockmgr() locks
> in other modules later on. The same structure can be used to implement
> both spin locks and normal blocking locks, and can handle shared,
> exclusive, and recursive-exclusive lock types. The critical path has
> been optimize down to 20 instructions or so ( compared to the hundreds
> in lockmgr() ).
>
> As many of you may already know, lockmgr() locks are extremely expensive
> and require interrupt synchronization for their internal simplelocks to
> operate properly in a mixed process/interrupt environment. The result is
> a horrendous amount of overhead for very little gain. I am attempting
> to come up with a general locking module that can eventually replace
> lockmgr() locks.
>
> -Matt
>
[...]
This brings up a couple of points..
1/ Who wrote the existing lock manager, and why did they do
it the way they did?. When soemone goes to so much trouble
over something it's usually for a reason.
2/ Before we rush off and implement a new set of locking primatives,
it might be a good idea to look at the locking primatives of a few
other OS's.. For example Linux and MACH, and if we can get hold of
them, Solaris and maybe the exokernel. (and sprite)
3/ This is not to say that what you have done is bad, but that there
is something to be said for not being gratuitously different. It
might also be the case that the other BSDs might be doing something
with locks.
4/ If you want to implement these locks it really is up to you to do
a quick scan of what the "state of the art" is in this field.
I think I can dig up MACH2.5 (OSF1/digital unix/true64) locks
maybe we should make a call for everyone on the freebsd lists to
see what they can find in their own back yards. Of course the use
of await() gives a good head start for us..
julian
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990627142319.8298I-100000>