Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966976Ab3E2Uhd (ORCPT ); Wed, 29 May 2013 16:37:33 -0400 Received: from g4t0017.houston.hp.com ([15.201.24.20]:30702 "EHLO g4t0017.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966821Ab3E2Uh0 (ORCPT ); Wed, 29 May 2013 16:37:26 -0400 Message-ID: <51A66701.6050104@hp.com> Date: Wed, 29 May 2013 16:37:21 -0400 From: Waiman Long User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12 MIME-Version: 1.0 To: Andi Kleen CC: Simo Sorce , 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" Subject: Re: [PATCH 0/3 v3] dcache: make it more scalable on large system 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> <20130529165603.GL6123@two.firstfloor.org> In-Reply-To: <20130529165603.GL6123@two.firstfloor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1310 Lines: 28 On 05/29/2013 12:56 PM, Andi Kleen wrote: > On Wed, May 29, 2013 at 12:18:09PM -0400, Simo Sorce wrote: >> 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. Just for clarification, the AIM7 workload is not affected by the current d_path() code, they are speed-limited by the lock contention in the dcache reference counting code. However, both the d_path() change and the dentry reference counting change are needed to to eliminate the overhead introduced by the use of the perf-record command. Regards, Longman -- 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/