On Fri, Apr 29, 2016 at 02:04:18PM +0200, Michal Hocko wrote: > I would also like to revisit generic inode/dentry shrinker and see > whether it could be more __GFP_FS friendly. As you say many FS might > even not depend on some FS internal locks so pushing GFP_FS check down > the layers might make a lot of sense and allow to clean some [id]cache > even for __GFP_FS context. That's precisely my point about passing a context to the shrinker. It's recursion within a single superblock context that makes up the majority of cases GFP_NOFS is used for, so passing the superblock immediately allows for reclaim to run the superblock shrinker on every other superblock. We can refine it further from there, but I strongly suspect that further refinement is going to require filesystems to specifically configure the superblock shrinker. e.g. in XFS, we can't allow evict() even on clean VFS inodes in a PF_FSTRANS context, because we may run a transaction on a clean VFS inode to prepare it for reclaim. We can, however, allow the fs-specific shrinker callouts to run (i.e. call into .free_cached_objects) so that it can reclaim clean XFS inodes because that doesn't require transactions.... i.e. the infrastructure I suggested we use is aimed directly at providing the mechanism required for finer-grained inode/dentry cache reclaim in contexts that it is currently disallowed completely. I was also implying that once the infrastructure to pass contexts is in place, I'd then make the changes to the generic superblock shrinker code to enable finer grained reclaim and optimise the XFS shrinkers to make use of it... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
