Re: mutexes, locks and so on...

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Nov 11, 2010 at 06:35:55PM +0100, Johnny Billquist wrote:
 >> [spl mutex stuff]
 > 
 > Hum? So that was introduced with the new locking code then? Because
 > back when we used splraise/splx, the above would not have worked.

This would have worked:

   s = splvm();
   slow_stuff_1();
   s2 = splhigh();
   fast_stuff();
   splx(s2);
   slow_stuff_2();
   splx(s);

When converted to the current mutex model, this runs slow_stuff_2() at
splhigh, which is probably undesirable. The conclusion is that there
isn't much code like this and any that remains should be rewritten.

There's also this; it would have been considered abusive in the old
days but that doesn't mean nobody ever wrote it:

   s = splhigh();
   fast_stuff();
   splvm();
   slow_stuff();
   splx(s);

 > >Also, AFAIK effect was was actually measured during newlock2 branch
 > >development.  Supporting such micro-optimisation would mean quite a bit
 > >of complexity in critical mutex(9) interface with practically no gain.
 > 
 > My initial reaction was that each mutex should have just stored
 > what ipl it came from, and just restored it back to that when the
 > mutex was released. That would also allow us to skip the mutex
 > count in cpu_info, as well as the global saved ipl in cpu_info, but
 > then I realized that this solution would break if people actually
 > wrote code like
 > lock(a)
 > lock(b)
 > release(a)
 > release(b)

...which is very common.

Keeping track of how many times each spl level has been asserted and
lowering to the right level at each mutex release does not add as much
complexity as rmind claims, and I'm not convinced it costs much either
(we've debated this before), but the model we have is only untidy, not
wrong, and I'm not interested enough to spend time benchmarking and
tuning to fix it.

 > Hmm. Hard to argue about this. While I think it's nice if we try to
 > keep the kernel agnostic, the user api is not something I'm arguing
 > about changing. But it would be nice if we could leave it possible
 > to do things in different ways when it's not really the effect of a
 > CAS that is needed, but we'd still like to keep it in a way that
 > allowed the compiled code to be as nice and efficient as possible.

It usually is a CAS that's needed. However, if it's worthwhile there's
no real reason the vax MD code couldn't provide its own versions of
higher-level actions that are by default written using CAS. There are
other old/slow platforms that could probably benefit from such hooks
if someone wanted to take the trouble to set things up accordingly.
The only question is whether it's really worth the maintenance
overhead of allowing it.

-- 
David A. Holland
dholland%netbsd.org@localhost