Ok, I've gone through -v7, and I'm sure you're all shocked to hear it, but
I have no complaints. Except that you dropped all the good commit
commentary you had earlier ;)
The patch looks pretty good (except for the big "#if 0" block in
mutex-debug.c that I hope gets fixed, but I can't even really claim that I
can be bothered), the locking looks fine (ie no locking at all), and the
numbers seem pretty convinving.
Oh, and I think the open-coded
atomic_cmpxchg(count, 1, 0) == 1
could possibly just be replaced with a simple __mutex_fastpath_trylock().
I dunno.
IOW, I'd actually like to take it, but let's give it at least a day or
two. Do people have any concerns?
And as far as I'm concerned, the nice part about not having any locking
there is that now the spinning has no impact what-so-ever on the rest of
the mutex logic. There are no subtleties about any of that - it's
literally about falling back to a (fairly educated) "try a few trylocks if
you fail". So it _looks_ pretty robust. I don't think there should be any
subtle interactions with anything else. If the old mutexes worked, then
the spinning should work.
Discussion?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
