On Thu, Apr 22, 2010 at 12:42:47PM -0400, Christoph Hellwig wrote: > On Fri, Apr 23, 2010 at 02:38:01AM +1000, Nick Piggin wrote: > > I don't understand, it should be implemented like just all the other > > shrinkers AFAIKS. Like the dcache one that has to shrink multiple > > superblocks. There is absolutely no requirement for this API change > > to implement it in XFS. > > The dcache shrinker is an example for a complete mess. Yes, it is, and one that I think we can clean up significantly by the use of context based shrinkers. IMO, a better approach to the VFS shrinkers is to leverage the fact we already have per-sb dentry LRUs and convert the inode cache to a per-sb LRU as well. We can then remove the current dependency problems by moving to a single context based shrinker (i.e. per-sb) to reclaim from the per-sb dentry LRU, followed by the per-sb inode LRU via a single shrinker. That is, remove the global scope from them because that is the cause of the shrinker call-order dependency problems. Further, if we then add a filesystem callout to the new superblock shrinker callout, we can handle all the needs of XFS (and other filesystems) without requiring them to have global filesystem lists and without introducing new dependencies between registered shrinkers. And given that the shrinker currently handles proportioning reclaim based on the number of objects reported by the cache, it also allows us to further simplify the dentry cache reclaim by removing all the proportioning stuff it does right now... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>