Re: [PATCH v2 1/4] mm/vmscan: fix anon-only reclaim evicting file pages when swappiness=max

[Ridong Chen <ridong.chen@linux.dev>]

On 7/18/2026 9:34 PM, Barry Song wrote:
> On Sat, Jul 18, 2026 at 5:54 PM Ridong Chen <ridong.chen@linux.dev> wrote:
>>
>> From: Ridong Chen <chenridong@xiaomi.com>
>>
>> As Qi mentioned [1], when swappiness=max (SWAPPINESS_ANON_ONLY) is set,
>> the reclaim logic is expected to reclaim anonymous pages exclusively.
>> However, due to the current ordering of checks in get_scan_count(),
>> file pages may still be evicted if can_reclaim_anon_pages() returns
>> false, which contradicts the semantics of SWAPPINESS_ANON_ONLY.
>>
>> Reproducer in a cgroup holding 64M of file cache, with no swap configured:
>>
>>    Before (file cache is wrongly evicted):
>>      # cat memory.stat
>>      anon 196608
>>      file 67178496
>>      pgscan_proactive 0
>>      # echo "64M swappiness=max" > memory.reclaim
>>      # cat memory.stat
>>      anon 208896
>>      file 4096                 <- page cache evicted
>>      pgsteal_proactive 16400
>>      pgscan_proactive 16400
>>
>>    After (file cache is left intact):
>>      # cat memory.stat
>>      anon 200704
>>      file 67178496
>>      pgscan_proactive 0
>>      # echo "64M swappiness=max" > memory.reclaim
>>      -bash: echo: write error: Resource temporarily unavailable
>>      # cat memory.stat
>>      anon 208896
>>      file 67178496             <- page cache untouched
>>      pgsteal_proactive 0
>>      pgscan_proactive 0
>>
>> Fix this by bailing out early when SWAPPINESS_ANON_ONLY is set and no
>> anonymous pages are reclaimable, before falling back to file reclaim.
>>
>> [1] https://lore.kernel.org/cgroups/7ddf3eee-5fe2-45f7-8614-c8936a039e04@linux.dev/
>>
>> Fixes: 68a1436bde00 ("mm: add swappiness=max arg to memory.reclaim for only anon reclaim")
>> Suggested-by: Qi Zheng <qi.zheng@linux.dev>
>> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
>> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
>> Reviewed-by: Muchun Song <muchun.song@linux.dev>
>> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
> 
> Reviewed-by: Barry Song <baohua@kernel.org>
> 
>> ---
>>   mm/vmscan.c | 18 +++++++++++-------
>>   1 file changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 35c3bb15ae96..d6b383d96a0c 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -2501,6 +2501,17 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
>>          enum scan_balance scan_balance;
>>          enum lru_list lru;
>>
>> +       /* Proactive reclaim initiated by userspace for anonymous memory only */
>> +       if (swappiness == SWAPPINESS_ANON_ONLY) {
>> +               WARN_ON_ONCE(!sc->proactive);
> 
> I feel it's a bit odd that the WARN_ON_ONCE() is placed here. Maybe
> adding a short comment would make the intent clearer. For example:
> "SWAPPINESS_ANON_ONLY is only allowed for proactive reclaim."

Hi Barry,

I didn't change the original logic in this patch. I agree that adding a 
comment would help clarify the intent.

I'll include that in the next version.

> I'm not sure whether it would be better to issue this warning earlier,
> for example in try_to_free_mem_cgroup_pages(). That said, I don't
> feel strongly about this.

Since patch 4 will address the MGLRU issue and could also include this 
warning, I think that triggering the warning earlier makes sense and 
would be more general. Would it be acceptable to add a separate patch 
(e.g., patch 5) for moving the warning? That way, each patch stays 
focused on a single logical change.

-- 
Best regards
Ridong