On Mon, Jul 11, 2011 at 03:21:44PM -0400, Christoph Hellwig wrote: > On Fri, Jul 08, 2011 at 02:14:40PM +1000, Dave Chinner wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > With the inode LRUs moving to per-sb structures, there is no longer > > a need for a global inode_lru_lock. The locking can be made more > > fine-grained by moving to a per-sb LRU lock, isolating the LRU > > operations of different filesytsems completely from each other. > > Btw, any reason this is not done for dcache_lru_lock? I have a patch that does exactly that, but it causes random crashes and oopsen in the dentry code due to corrupted lists and dentries when running xfstests. Like the inode cache, it is a simple translation of dcache_lru_lock to sb->s_dentry_lru_lock, so it should not be changing what is protected by the LRU lock. The patch used to work fine before the massive locking rework of the dentry cache, so it appears that there is now something unknown that dcache_lru_lock is implicitly protecting. However, the locking is now so complex I've been unable to debug the problems caused by the patch, so I simply dropped the patch. I might try again later to break up the dcache_lru_lock, but right now it's not showing up as a badly contended lock in my tests and I've got other things that are more important to do, so I've been ignoring the problem.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>