Re: btrfs_tree_lock & trylock

[Andi Kleen <andi@firstfloor.org>]

On Mon, Sep 08, 2008 at 08:07:51AM -0700, Stephen Hemminger wrote:
> 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.

At least the numbers done by Gregory et.al. were dramatic improvements.
Given that was an extreme case in that the rt kernel does everything
with mutexes, but it was still a very clear win on a wide range
of workloads.

-Andi