Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966951Ab3E2UlI (ORCPT ); Wed, 29 May 2013 16:41:08 -0400 Received: from g4t0016.houston.hp.com ([15.201.24.19]:24756 "EHLO g4t0016.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966083Ab3E2Uk5 (ORCPT ); Wed, 29 May 2013 16:40:57 -0400 Message-ID: <51A667D4.4050301@hp.com> Date: Wed, 29 May 2013 16:40:52 -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: "J. Bruce Fields" CC: 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 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> <20130529184640.GA3243@fieldses.org> In-Reply-To: <20130529184640.GA3243@fieldses.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: 2125 Lines: 40 On 05/29/2013 02:46 PM, J. Bruce Fields wrote: > On Wed, May 29, 2013 at 11:55:14AM -0400, Waiman Long wrote: >> On 05/26/2013 10:09 PM, Dave Chinner wrote: >>> On Thu, May 23, 2013 at 05:34:23PM -0400, Waiman Long wrote: >>>> On 05/23/2013 05:42 AM, Dave Chinner wrote: >>>>> What was it I said about this patchset when you posted it to speed >>>>> up an Oracle benchmark back in february? I'll repeat: >>>>> >>>>> "Nobody should be doing reverse dentry-to-name lookups in a quantity >>>>> sufficient for it to become a performance limiting factor." >>>> Thank for the comment, but my point is that it is the d_lock >>>> contention is skewing the data about how much spin lock contention >>>> had actually happened in the workload and it makes it harder to >>>> pinpoint problem areas to look at. This is not about performance, it >>>> is about accurate representation of performance data. Ideally, we >>>> want the overhead of turning on perf instrumentation to be as low as >>>> possible. >>> Right. But d_path will never be "low overhead", and as such it >>> shouldn't be used by perf. >> The d_path() is called by perf_event_mmap_event() which translates >> VMA to its file path for memory segments backed by files. As perf is >> not just for sampling data within the kernel, it can also be used >> for checking access pattern in the user space. As a result, it needs >> to map VMAs back to the backing files to access their symbols >> information. If d_path() is not the right function to call for this >> purpose, what other alternatives do we have? > As Dave said before, is the last path component sufficient? Or how > about an inode number? I don't think so. The user-space perf command will need the full pathname to locate the binaries and read their debug information. Just returning the last path component or the inode number will not cut it. 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/