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

[Arjan van de Ven <arjan@infradead.org>]

On Wed, 2005-12-14 at 11:24 +0000, Alan Cox wrote:
> On Mer, 2005-12-14 at 12:08 +0100, Arjan van de Ven wrote:
> > 1) the BKL change hasn't finished, and we're 5 years down the line. API
> > changes done gradual tend to take forever in practice, esp if there's no
> > "compile" incentive for people to fix things. 
> 
> This isn't a "fix" however, its merely a performance tweak.

it's a conceptual API split that, if nothing else, declares intent and
usage pattern more specifically. Performance is just one of the angles.
Other angles are that it's possible to treat mutex users different (like
Ingo is doing in -rt, where you can temporary boost a mutex owner if the
mutex gets contended, other uses are better hold time metrics etc etc)

>  Drivers
> using the old API are not a problem because
> 
> a) The old API is needed long term for true counting sem users

this is skipping one bridge ;)
A counting semaphore is needed long term. API is up for debate in the
sense that it's not clear that a non-compile-time thing is the right
solution.

> Thats rather different to the BKL

BKL is different in that it's more work to do a conversion (eg the BKL
semantics are rather complex compared to normal spinlock / semaphore /
mutex semantics). So yes BKL is harder, and not really possible to do in
one go. Unlike these...
For BKL there was no choice. Here there is.