Re: btrfs_tree_lock & trylock

[Stephen Hemminger <shemminger@vyatta.com>]

On Mon, 8 Sep 2008 16:20:52 +0200
Andi Kleen <andi@firstfloor.org> wrote:

> On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote:
> > On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote:
> > > > The idea is to try to spin for a bit to avoid scheduling away, which is
> > > > especially important for the high levels.  Most holders of the mutex
> > > > let it go very quickly.
> > > 
> > > Ok but that surely should be implemented in the general mutex code then
> > > or at least in a standard adaptive mutex wrapper? 
> > 
> > That depends, am I the only one crazy enough to think its a good idea?
> 
> Adaptive mutexes are classic, a lot of other OS have it.

The problem is that they are a nuisance. It is impossible to choose
the right trade off between spin an no-spin, also they optimize for
a case that doesn't occur often enough to be justified.

People seem to repeatedly come up with adaptive mutex based on intuitive
hunch, and never do much analysis before or afterwards.

You need some facts to come up with a useful model:
  % of time lock is contended
  average lock hold time
  overhead of entry-exit for lock primitive (spin time)
  overhead of the adaptive version either pure spin or pure mutex

Also, adaptive locks have even worse unfairness than spin locks under
contention.