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

[Kefeng Wang <wangkefeng.wang@huawei.com>]

On 4/9/2026 9:01 PM, Michal Hocko wrote:
> 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.


For proactive reclaim, there are three interface for now,
1) lru_gen:  called lru_gen_seq_write()
2) memcg.reclaim/per-node-reclaim :  called user_proactive_reclaim（）


I think it is reasonable to provide more strategic options for user 
proactive reclaim. The new code changes the semantic of lru_gen/per-
node-reclaim, but not memcg, so if we do need to avoid potential
regression, maybe add something like swappiness=min to only reclaim
file page.