Dave Chinner <david@xxxxxxxxxxxxx> writes: > On Fri, Oct 08, 2010 at 04:32:19PM -0700, Frank Mayhar wrote: >> Nick Piggin has been doing work on lock contention in VFS, in particular >> to remove the dcache and inode locks, and we are very interested in this >> work. He has entirely eliminated two of the most contended locks, >> replacing them with a combination of more granular locking, seqlocks, >> RCU lists and other mechanisms that reduce locking and contention in >> general. He has published this work at >> >> git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git ... > > While the code in that tree might be stable, it's not really in any > shape acceptible for mainline inclusion. > > I've been reworking the inode_lock breakup code from this patch set, > and there is significant change in the locking order and structure > compared to the above tree to avoid the unmaintainable mess of > trylock operations that Nick's patchset ended up with. ... > > FWIW, it would be good if this sort of testing could be run on the tree > under review here: > > git://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfsdev.git inode-scale > > This is what I'm trying to get reviewed in time for a .37 merge. If > that gets in .37, then I'll probably follow the same process for the > dcache_lock in .38, and after that we can then consider all the RCU > changes for both the inode and dentry operations. That would be over 6 months just to make even a little progress. Sorry, I am not convinced yet that any progress in this area has to be that glacial. Linus indicated last time he wanted to move faster on the VFS improvements. And the locking as it stands today is certainly a major problem. Maybe it's possible to come up with a way to integrate this faster? -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>