Re: [PATCH][RFC]: mutex: adaptive spin

[Gregory Haskins]

Peter Zijlstra wrote:
> On Tue, 2009-01-06 at 14:16 +0100, Ingo Molnar wrote:
>   
>> * Gregory Haskins <ghaskins@xxxxxxxxxx> wrote:
>>
>>     
>>> Ingo Molnar wrote:
>>>       
>>>> There's no time or spin-rate based heuristics in this at all (i.e. these 
>>>> mutexes are not 'adaptive' at all!),
>>>>         
>>> FYI: The original "adaptive" name was chosen in the -rt implementation 
>>> to reflect that the locks can adaptively spin or sleep, depending on 
>>> conditions.  I realize this is in contrast to the typical usage of the 
>>> term when it is in reference to the spin-time being based on some 
>>> empirical heuristics, etc as you mentioned.  Sorry for the confusion.
>>>       
>> the current version of the -rt spinny-mutexes bits were mostly written by 
>> Steve, right? Historically it all started out with a more classic 
>> "adaptive mutexes" patchset so the name stuck i guess.
>>     
>
> Yeah, Gregory and co. started with the whole thing and showed there was
> significant performance to be gained, after that Steve rewrote it from
> scratch reducing it to this minimalist heuristic, with help from Greg.
>
> (At least, that is how I remember it, please speak up if I got things
> wrong)
>   
Thats pretty accurate IIUC.  The concept and original patches were
written by myself, Peter Morreale and Sven Dietrich (cc'd).  However,
Steve cleaned up our patch before accepting it into -rt (we had extra
provisions for things like handling conditional compilation and run-time
disablement which he did not care for), but its otherwise the precise
core concept we introduced.  I think Steven gave a nice attribution to
that fact in the prologue, however.  And I also ACKed his cleanup, so I
think all is well from my perspective.

As a historical note: It should be mentioned that Steven also introduced
a really brilliant optimization to use RCU for the owner tracking that
the original patch as submitted by my team did not have.  However, it
turned out to inadvertently regress performance due to the way
preempt-rcu's rcu_read_lock() works so it had to be reverted a few weeks
later to the original logic that we submitted (even though on paper his
ideas in that area were superior to ours).  So whats in -rt now really
is more or less our patch sans the conditional crap, etc. 

Hope that helps!

-Greg

Attachment: signature.asc
Description: OpenPGP digital signature