> 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? In principle it should be only called for new file mappings getting maped. Do you really have that many new file mappings all the time? Or is this related to program startup? > > My patch set consists of 2 different changes. The first one is to > avoid taking the d_lock lock when updating the reference count in > the dentries. This particular change also benefit some other > workloads that are filesystem intensive. One particular example is > the short workload in the AIM7 benchmark. One of the job type in the > short workload is "misc_rtns_1" which calls security functions like > getpwnam(), getpwuid(), getgrgid() a couple of times. These > functions open the /etc/passwd or /etc/group files, read their > content and close the files. It is the intensive open/read/close > sequence from multiple threads that is causing 80%+ contention in > the d_lock on a system with large number of cores. The MIT's > MOSBench paper also outlined dentry reference counting as a The paper was before Nick Piggin's RCU (and our) work on this. Modern kernels do not have dcache problems with mosbench, unless you run weird security modules like SMACK that effectively disable dcache RCU. BTW lock elision may fix these problems anyways, in a much simpler way. -Andi ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- 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
