Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759579Ab3E2Q4O (ORCPT ); Wed, 29 May 2013 12:56:14 -0400 Received: from one.firstfloor.org ([193.170.194.197]:36660 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755365Ab3E2Q4F (ORCPT ); Wed, 29 May 2013 12:56:05 -0400 Date: Wed, 29 May 2013 18:56:03 +0200 From: Andi Kleen To: Simo Sorce Cc: Waiman Long , Dave Chinner , Alexander Viro , Jeff Layton , Miklos Szeredi , Ian Kent , Sage Weil , Steve French , Trond Myklebust , Eric Paris , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, autofs@vger.kernel.org, ceph-devel@vger.kernel.org, linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org, "Chandramouleeswaran, Aswin" , "Norton, Scott J" , Andi Kleen Subject: Re: [PATCH 0/3 v3] dcache: make it more scalable on large system Message-ID: <20130529165603.GL6123@two.firstfloor.org> References: <1369273048-60256-1-git-send-email-Waiman.Long@hp.com> <20130523094201.GA24543@dastard> <519E8B5F.3080905@hp.com> <20130527020903.GR29466@dastard> <51A624E2.3000301@hp.com> <1369844289.2769.146.camel@willson.li.ssimo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1369844289.2769.146.camel@willson.li.ssimo.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1955 Lines: 41 On Wed, May 29, 2013 at 12:18:09PM -0400, Simo Sorce wrote: > On Wed, 2013-05-29 at 11:55 -0400, Waiman Long wrote: > > > My patch set consists of 2 different changes. The first one is to avoid > > taking the d_lock lock when updating the reference count in the > > dentries. This particular change also benefit some other workloads that > > are filesystem intensive. One particular example is the short workload > > in the AIM7 benchmark. One of the job type in the short workload is > > "misc_rtns_1" which calls security functions like getpwnam(), > > getpwuid(), getgrgid() a couple of times. These functions open the > > /etc/passwd or /etc/group files, read their content and close the files. > > It is the intensive open/read/close sequence from multiple threads that > > is causing 80%+ contention in the d_lock on a system with large number > > of cores. > > To be honest a workload base on /etc/passwd or /etc/group is completely > artificial, in actual usage, if you really have such access you use > nscd or sssd with their shared memory caches to completely remove most > of the file access. I don't fully agree at this point. A lot of things can be tuned away, but in practice we want things to perform well out of the box without needing all kinds of magic tuning that only Also this is just normal file access, nothing special about it. It simply has to scale. For all kinds of workloads. And it does, just d_path messes it up. > I have no beef on the rest but repeated access to Nsswitch information > is not something you need to optimize at the file system layer and > should not be brought up as a point in favor. This is about repeated access to arbitrary files. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/