Re: [PATCH RFC] fs: drop_caches: introduce per-node drop_caches interface

[Michal Hocko <mhocko@suse.com>]

On Thu 09-04-26 20:50:33, Kefeng Wang wrote:
> 
> 
> On 4/9/2026 6:52 PM, Michal Hocko wrote:
> > On Thu 09-04-26 16:54:48, Kefeng Wang wrote:
> > > 
> > > 
> > > On 4/9/2026 4:22 PM, Michal Hocko wrote:
> > > > On Thu 09-04-26 16:08:37, Kefeng Wang wrote:
> > > > [...]
> > > > > To use the reclaim interface, there are two differences,
> > > > > 
> > > > > 1) we need to input the reclaim numbers and swappiness, this is not a big
> > > > > problem
> > > > > 2) for reclaim, it supports swappiness=max to only reclaim anonymous pages,
> > > > > but cannot only reclaim file pages,
> > > > 
> > > > Why is 2) a real constrain?
> > > 
> > > This should not be a restriction, but a strategy. Our product wants to
> > > migrate anonymous pages to the local instead of swapping them out. However,
> > > the current per-node-reclaim interface does not support reclaiming only file
> > > pages.
> > 
> > Yes, I do understand that you want to keep your hot anonymous pages
> > resident on some node. Those shouldn't be reclaimed by the user space
> > triggered reclaim anyway, right? Migration will then happen during the
> > memory offlining.
> 
> Yes, that we need.
> > 
> > This will certainly require some fine tuning but I do not see any reason
> > this should be completely impossible. Certainly a more robust way (from
> > API POV) than the suggested drop_caches. I am also not convinced we need
> > page-cache-only reclaim for the existing reclaim interface. I believe it
> > makes more sense to look at the reclaim from hotness POV rather than
> > anon vs. file.
> 
> It is already support only reclaim file pages when swappiness = 0 for
> memcg.reclaim, but not for per-node-reclaim, so we can just make a few
> small changes to enable it(no tested)

This might be small changes wrt code impact but they are changing the
semantic of the interface and that needs proper analysis of impact,
potential regression risk and also evaluate whether this is what we
really want/need. Memcg has been special in this regards from early on
and we pretty much had to keep the status quo IIRC.

-- 
Michal Hocko
SUSE Labs