Messages in this thread | | | Subject | Re: Btrfs for mainline | From | Chris Mason <> | Date | Mon, 05 Jan 2009 09:34:23 -0500 |
| |
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
| |