On 06/06/2013 03:07 AM, 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? > > 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? > > This is preparation for the whole point of this series, which is to abstract the lru manipulation into a list_lru. It is hard to do that when the dcache has a single lock for all manipulations, and multiple lists under its umbrella. -- 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
