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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
