On Sun, 2009-01-04 at 19:21 +0100, Peter Zijlstra wrote: > On Sat, 2009-01-03 at 12:17 -0700, Matthew Wilcox wrote: > > > - locking.c needs a lot of cleanup. > > > If combination spinlocks/mutexes are really a win they should be > > > in the generic mutex framework. And I'm still dubious on the > > hardcoded > > > numbers. > > > > I don't think this needs to be cleaned up before merge. I've spent > > an hour or two looking at it, and while we can do a somewhat better > > job as part of the generic mutex framework, it's quite tricky (due to > > the different <asm/mutex.h> implementations). It has the potential to > > introduce some hard-to-hit bugs in the generic mutexes, and there's some > > API discussions to have. > > I'm really opposed to having this in some filesystem. Please remove it > before merging it. > It is 5 lines in a single function that is local to btrfs. I'll be happy to take it out when a clear path to a replacement is in. I know people have been doing work in this area for -rt, and do not want to start a parallel effort to change things. I'm not trying to jump into the design discussions because there are people already working on it who know the issues much better than I do. But, if anyone working on adaptive mutexes is looking for a coder, tester, use case, or benchmark for their locking scheme, my hand is up. Until then, this is my for loop, there are many like it, but this one is mine. -chris -- 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
