@@ -316,11 +316,9 @@ The detailed design for rcu-walk is like this:
316316
317317The cases where rcu-walk cannot continue are:
318318* NULL dentry (ie. any uncached path element)
319- * parent with d_inode->i_op->permission or ACLs
320319* Following links
321320
322- In future patches, permission checks become rcu-walk aware. It may be possible
323- eventually to make following links rcu-walk aware.
321+ It may be possible eventually to make following links rcu-walk aware.
324322
325323Uncached path elements will always require dropping to ref-walk mode, at the
326324very least because i_mutex needs to be grabbed, and objects allocated.
@@ -336,9 +334,49 @@ or stored into. The result is massive improvements in performance and
336334scalability of path resolution.
337335
338336
337+ Interesting statistics
338+ ======================
339+
340+ The following table gives rcu lookup statistics for a few simple workloads
341+ (2s12c24t Westmere, debian non-graphical system). Ungraceful are attempts to
342+ drop rcu that fail due to d_seq failure and requiring the entire path lookup
343+ again. Other cases are successful rcu-drops that are required before the final
344+ element, nodentry for missing dentry, revalidate for filesystem revalidate
345+ routine requiring rcu drop, permission for permission check requiring drop,
346+ and link for symlink traversal requiring drop.
347+
348+ rcu-lookups restart nodentry link revalidate permission
349+ bootup 47121 0 4624 1010 10283 7852
350+ dbench 25386793 0 6778659(26.7%) 55 549 1156
351+ kbuild 2696672 10 64442(2.3%) 108764(4.0%) 1 1590
352+ git diff 39605 0 28 2 0 106
353+ vfstest 24185492 4945 708725(2.9%) 1076136(4.4%) 0 2651
354+
355+ What this shows is that failed rcu-walk lookups, ie. ones that are restarted
356+ entirely with ref-walk, are quite rare. Even the "vfstest" case which
357+ specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to excercise
358+ such races is not showing a huge amount of restarts.
359+
360+ Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where
361+ the reference count needs to be taken for some reason. This is either because
362+ we have reached the target of the path walk, or because we have encountered a
363+ condition that can't be resolved in rcu-walk mode. Ideally, we drop rcu-walk
364+ only when we have reached the target dentry, so the other statistics show where
365+ this does not happen.
366+
367+ Note that a graceful drop from rcu-walk mode due to something such as the
368+ dentry not existing (which can be common) is not necessarily a failure of
369+ rcu-walk scheme, because some elements of the path may have been walked in
370+ rcu-walk mode. The further we get from common path elements (such as cwd or
371+ root), the less contended the dentry is likely to be. The closer we are to
372+ common path elements, the more likely they will exist in dentry cache.
373+
374+
339375Papers and other documentation on dcache locking
340376================================================
341377
3423781. Scaling dcache with RCU (http://linuxjournal.com/article.php?sid=7124).
343379
3443802. http://lse.sourceforge.net/locking/dcache/dcache.html
381+
382+
0 commit comments