Re: Progress on scaling of FreeBSD on 8 CPU systems

On Sun, 25 Feb 2007, Ivan Voras wrote:

> Kris Kennaway wrote:
>
>> Hopefully within a week or two.  It might not be that exact patch, I
>> think John wants to try and do it a bit differently instead of
>> introducing a new locking primitive just for this.
>
> Well why not? :) I am not an expert, but reading jeffr's posts it looks like 
> the idea of sleepable mutexes was taken from Solaris, where it's also not 
> exactly documented. If moving away from sleepable mutexes introduces more 
> than a small single digit percentage drop in performance (1% on 
> multi-gigahertz machines is a lot), why not keep it? If it's dangerous to 
> use, that should be documented in the man page with big bold letters but if 
> it helps, keep it.
>
> (Of course I might be completely off the track and sleepable mutexes might 
> be inconsequential for performance here :) )

Well, there are two ways you can ask the question about locks here:

(1) Why don't we allow sleeping with mutexes?

(2) Why don't the sleepable locking primitives perform better?

There are now patches that address this from both sides, optimizing sx lock 
performance and allowing mutexes to sleep.  There are serious deadlock issues 
that can arise with sleepable mutexes; I believe Jeff's patch includes the 
necessary bits to teach WITNESS how to detect some misuse at run-time. Right 
now, with the exception of the fast interrupt context, mutexes are universally 
acquirable in any context subject to lock order.  If we have sleepable 
mutexes, this will no longer be true, which is a significant change in the 
constraints on use. Attilio has a heavily optimized sxlock implementation as 
well, although I'm not sure the two have been benchmarked side-by-side, but 
that would be an obvious next thing to try.

Robert N M Watson
Computer Laboratory
University of Cambridge