On Wed, 2009-01-07 at 09:50 -0800, Linus Torvalds wrote:

On Wed, 7 Jan 2009, Chris Mason wrote:

quoted

So far I haven't found any btrfs benchmarks where this is slower than
mutexes without any spinning.  But, it isn't quite as fast as the btrfs
spin.

Quite frankly, from our history with ext3 and other filesystems, using a 
mutex in the filesystem is generally the wrong thing to do anyway. 

Are you sure you can't just use a spinlock, and just release it over IO? 
The "have to do IO or extend the btree" case is usually pretty damn clear.

Because it really sounds like you're lock-limited, and you should just try 
to clean it up. A pure "just spinlock" in the hotpath is always going to 
be better.

There are definitely ways I can improve performance for contention in
the hot btree nodes, and I think it would be a mistake to tune the
generic adaptive locks just for my current code.

But, it isn't a bad test case to compare the spin with the new patch and
with the plain mutex.  If the adaptive code gets in, I think it would be
best for me to drop the spin.

Either way there's more work to be done in the btrfs locking code.

-chris