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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux