On Tue 23-03-21 12:28:20, Daniel Vetter wrote: > On Tue, Mar 23, 2021 at 08:38:33AM +0100, Michal Hocko wrote: [...] > > > > fs_reclaim_acquire is there to make sure lockdep understands that this > > > > is a shrinker and that it checks all the dependencies for us like if > > > > we'd be in real reclaim. There is some drop caches interfaces in proc > > > > iirc, but those drop everything, and they don't have the fs_reclaim > > > > annotations to teach lockdep about what we're doing. > > > > ... I really do not follow this. You shouldn't really care whether this > > is a reclaim interface or not. Or maybe I just do not understand this... > > We're heavily relying on lockdep and fs_reclaim to make sure we get it all > right. So any drop caches interface that isn't wrapped in fs_reclaim > context is kinda useless for testing. Plus ideally we want to only hit our > own paths, and not trash every other cache in the system. Speed matters in > CI. But what is special about this path to hack around and make it pretend it is part of the fs reclaim path? -- Michal Hocko SUSE Labs _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
