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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
