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 autofs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
