From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [PATCH 0/3 v3] dcache: make it more scalable on large system Date: Wed, 29 May 2013 14:46:40 -0400 Message-ID: <20130529184640.GA3243@fieldses.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Chinner , Alexander Viro , Jeff Layton , Miklos Szeredi , Ian Kent , Sage Weil , Steve French , Trond Myklebust , Eric Paris , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, autofs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Chandramouleeswaran, Aswin" , "Norton, Scott J" , Andi Kleen To: Waiman Long Return-path: Content-Disposition: inline In-Reply-To: <51A624E2.3000301-VXdhtT5mjnY@public.gmane.org> Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: 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? --b. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965845Ab3E2SrG (ORCPT ); Wed, 29 May 2013 14:47:06 -0400 Received: from fieldses.org ([174.143.236.118]:53957 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965413Ab3E2SrD (ORCPT ); Wed, 29 May 2013 14:47:03 -0400 Date: Wed, 29 May 2013 14:46:40 -0400 To: Waiman Long 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 Message-ID: <20130529184640.GA3243@fieldses.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51A624E2.3000301@hp.com> User-Agent: Mutt/1.5.21 (2010-09-15) From: "J. Bruce Fields" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? --b.