On Wed, May 29, 2013 at 11:55:14AM -0400, Waiman Long wrote:On 05/26/2013 10:09 PM, Dave Chinner wrote:As Dave said before, is the last path component sufficient? Or howOn Thu, May 23, 2013 at 05:34:23PM -0400, Waiman Long wrote:The d_path() is called by perf_event_mmap_event() which translatesOn 05/23/2013 05:42 AM, Dave Chinner wrote:Right. But d_path will never be "low overhead", and as such itWhat was it I said about this patchset when you posted it to speedThank for the comment, but my point is that it is the d_lock
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."
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.
shouldn't be used by perf.
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?
about an inode number?