On Thursday June 22, dhowells@xxxxxxxxxx wrote: > > Hi Neil, > > I'd like to propose an alternative to your patch to fix the dcache race > between unmounting a filesystem and the memory shrinker. > > In my patch, generic_shutdown_super() is made to call shrink_dcache_sb() > instead of shrink_dcache_anon(), and the latter function is discarded > completely since it's no longer used. Is that a good idea? I was under the impression that on large machines, the shear size of the dentry_unused list makes scanning all of it under the dcache_lock an unpleasant thing to do. Do you not have easy access to the roots of all trees in your super-block-sharing situation so that shrink_dcache_parent can be called on them all? I would have thought that we want to get rid of shrink_dcache_sb rather than create more users of it ?? > > I feel that prune_dcache() should probably at some point be merged into its > two callers, since shrink_dcache_parent() and select_parent() can probably > then do a better job of eating a dentry subtree from the leaves inwards, but I > haven't attempted that with this patch. > I think this is true, prune_dcache is serving two masters and is overly complex as a result. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
