On Thu, 30 May 2013 11:48:50 -0400, Waiman Long wrote: > On 05/29/2013 05:19 PM, Jörn Engel wrote: > >On Wed, 29 May 2013 22:37:00 +0200, Andi Kleen wrote: > >>>As Dave said before, is the last path component sufficient? Or how > >>>about an inode number? > >>Neither works, the profiler needs to find the file and read it. > >Ignoring all the complexity this would cause downstream, you could do > >the path lookup just once, attach some cookie to it and return the > >cookie ever-after. Maybe some combination of i_sb and i_ino would be > >good enough as a cookie. > > Still, it is just shifting the complexity from the d_path code to > the perf kernel subsystem as it needs to keep track of what paths > have been sent up before. That sounds like a good thing to have. Every single linux user depends on the dcache. Only a relatively small subset cares about perf. Having dcache pay the cost for perf's special needs is a classical externality. > It also have complications in case the > tracked files are being deleted or moved around in the filesystem. > Some kind of notification mechanism has to be implemented in the > dentry layer to notify the perf subsystem. Agreed. The whole approach is based on getting the 99% case right and occasionally being wrong. For perf this may be acceptable, not sure. Jörn -- Without a major sea change, nothing that is under copyright today will ever come out from under it and fall into the public domain. -- Jake Edge -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
