Re: Progress on scaling of FreeBSD on 8 CPU systems

On Sunday 25 February 2007 05:56, Robert Watson wrote:
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.

My intention is to both get the sx locks changes into the tree so that sx
locks use atomic ops, and to add a new sleep lock primitive that is like a
mutex but uses sleepq rather than turnstiles. The latter is a lot like
Jeff's top-half mutex just with some slight tweaks, and as a separate lock
primitive.

--
John Baldwin
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: all mutexes -> read-write locks?
    ... locking primitives it has come to be that mutexes and exclusively ... acquired reader-writer locks are almost the same in terms of overhead ... by all means change it to use rwlocks. ... changing it would allow a slow transition to using rw locks. ...
    (freebsd-arch)
  • Re: [RFC] locking.9
    ... Sleep Mutexes ... Shared-Exclusive locks ... deschedules the thread while you are holding a SPIN mutex. ... .Ss Sleep Mutexes ...
    (freebsd-current)
  • [RFC] locking.9
    ... Sleep Mutexes ... Shared-Exclusive locks ... deschedules the thread while you are holding a SPIN mutex. ... .Ss Sleep Mutexes ...
    (freebsd-current)
  • Re: locking N mutexes simultaneously
    ... I need to map N mutexes to a sorted array of M mutexes ... acquire locks A B C D E while T2 tries for C E F, ... Lockers of the multimethod simultaneously otherwise I would create ... OBJ queue1 = new; ...
    (comp.programming.threads)
  • Re: all mutexes -> read-write locks?
    ... locking primitives it has come to be that mutexes and exclusively ... acquired reader-writer locks are almost the same in terms of overhead ...
    (freebsd-arch)