On Wed, Jun 05, 2013 at 04:07:38PM -0700, Andrew Morton wrote: > On Mon, 3 Jun 2013 23:29:33 +0400 Glauber Costa <glommer@xxxxxxxxxx> wrote: > > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > With the dentry LRUs being per-sb structures, there is no real need > > for a global dentry_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. > > What's the point to this patch? Is it to enable some additional > development, or is it a standalone performance tweak? It's the separation of the global lock into locks of the same scope the generic LRU list requires. > If the latter then the patch obviously makes this dentry code bloatier > and straight-line slower. So we're assuming that the multiprocessor > contention-avoidance benefits will outweigh that cost. Got any proof > of this? Well, it will do that too for workloads that span multiple filesytems, but that isn't the point of the patch. it's merely a setting stone... 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>