Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation

[David Howells <dhowells@redhat.com>]

Linus Torvalds <torvalds@osdl.org> wrote:

> Dammit, unless the pure mutex has a _huge_ performance advantage on major 
> architectures, we're not changing it.

Whilst it's true that the major archs are generally where the least advantage
will be seen, consider the following points:

 (1) The major archs are generally the ones where consuming a few extra bytes
     of kernel code so as to hold the slow paths for the mutexes would matter
     least.

 (2) The minor archs are where the performance gain would be most noticable
     because many of them only have unconditional state substitution
     capabilities (XCHG/TAS/SWAP/BSET), and no matter how much you may not
     care for them, they do matter.

     Having to use spinlocks and interrupt disablement in lieu of conditional
     state substitution (such as CMPXCHG) can cost quite a bit.

 (3) Mutex performance should in no way be slower on any arch than counting
     semaphores being used to do the same job. Now, admittedly, my first
     attempt was suboptimal for archs that have better-than-XCHG capabilities,
     but I've amended that with Ingo's help, just not released it yet.

> There's absolutely zero point. A counting semaphore is a perfectly fine
> mutex

But that isn't so in one particular case: debugging. A mutex would balk at a
double-release, but a counting semaphore will just silently let things go
wrong, because that's the nature of the beast.

> - the fact that it can _also_ be used to allow more than 1 user into a
> critical region and generally do other things is totally immaterial.

There are about a dozen such uses of counting semaphores in the kernel, and
they're mainly used as token/message counters.

> It's _extra_ stupid to re-use the names "down()" and "up()" on a 
> non-counting mutex, since then the names make zero sense at all. Use 
> "lock_mutex()" and "unlock_mutex()" or something, and don't break existing 
> code for no measurable gain.

Okay. Repurposing up(), down(), DECLARE_MUTEX() and init_MUTEX() had the major
benefit that the kernel required relatively few changes. The biggest problem
with doing a whole new mutex type with a new and different API is that
DECLARE_MUTEX and init_MUTEX are already taken... :-/

David