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. The -rt tree has adaptive spin patches for the rtmutex code, its really not all that hard to do -- the rtmutex code is way more tricky than the regular mutexes due to all the PI fluff. For kernel only locking the simple rule: spin iff the lock holder is running proved to be simple enough. Any added heuristics like max spin count etc. only made things worse. The whole idea though did make sense and certainly improved performance. We've also been looking at doing adaptive spins for futexes, although that does get a little more complex, furthermore, we've never gotten around to actually doing any code on that. -- 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
