Re: btrfs_tree_lock & trylock

[Stephen Hemminger <shemminger@vyatta.com>]

On Mon, 08 Sep 2008 12:20:32 -0400
Chris Mason <chris.mason@oracle.com> wrote:

> 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
> 
> 

Not to mention the problem that developers seem to have faster machines than
average user, but slower than the enterprise and future generation CPU's.
So any tuning value seems to get out of date fast.