Re: [PATCH v10 04/35] dentry: move to per-sb LRU locks

[Glauber Costa <glommer@parallels.com>]

On 06/06/2013 12:03 PM, Glauber Costa wrote:
> On 06/06/2013 03:07 AM, Andrew Morton wrote:
>> On Mon,  3 Jun 2013 23:29:33 +0400 Glauber Costa <glommer@openvz.org> wrote:
>>
>>> From: Dave Chinner <dchinner@redhat.com>
>>>
>>> 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.
> 
> 

I have updated the Changelog, that now reads:

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. The need for this is independent
of any performance consideration that may arise: in the interest of
abstracting the lru operations away, it is mandatory that each lru works
around its own lock instead of a global lock for all of them.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>