On Wed, 2010-06-30 at 21:30 +1000, Dave Chinner wrote: > Sure, but I have to question how much of this is actually necessary? > A lot of it looks like scalability for scalabilities sake, not > because there is a demonstrated need... Well, we've repeatedly run into problems with contention on the dcache_lock as well as the inode_lock; changes that improve those paths are extremely interesting to us. I've also seen numbers from systems with large (i.e. 32 to 64) numbers of cores that clearly show serious problems in this area. Further, while this seems like a bunch of patches, a close look shows that it basically just pushes the dcache and inode locks down as far as possible, making other improvements (such as removal of a few atomics and no longer batching inode reclaims, among other things) based on that work. I would be hard-pressed to find much to cherry-pick from this patch set. One interesting thing might be to do a set of performance tests for kernels with increasingly more of the patchset, just to see the effect of the earlier patches against a vanilla kernel and to measure the cumulative effect of the later patches. (I'm not volunteering, however: ENOTIME.) -- Frank Mayhar <fmayhar@xxxxxxxxxx> Google, Inc. -- 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
