Re: btrfs_tree_lock & trylock

[Chris Mason <chris.mason@oracle.com>]

On Mon, 2008-09-08 at 12:13 -0400, jim owens wrote:
> Chris Mason wrote:
> >> My guess is that the improvement happens mostly from the first couple of tries,
> >> not from repeated spinning. And since it is a mutex, you could even do:
> > 
> > I started with lower spin counts, I really didn't want to spin at all
> > but the current values came from trial and error.
> 
> Exactly the problem Steven is saying about adaptive locking.
> 
> Using benchmarks (or any test), on a small sample of systems
> leads you to conclude "this design/tuning combination is better".
> 
> I've been burned repeatedly by that... ugly things happen
> as you move away from your design testing center.
> 
> I'm not saying your code does not work, just that we need
> a lot more proof with different configurations and loads
> to see that is "at least no worse".

Oh, I completely agree.  This is tuned on just one CPU in a handful of
workloads.  In general, it makes sense to spin for about as long as it
takes someone to do a btree search in the block, which we could
benchmark up front at mount time.

I could also get better results from an API where the holder of the lock
indicates it is going to hold on to things for a while, which might
happen right before doing an IO.

Over the long term these are important issues, but for today I'm focused
on the disk format ;)

-chris