Re: [PATCH] mm: vmscan: always allow writeback during memcg reclaim

[Johannes Weiner <hannes@cmpxchg.org>]

On Sat, Dec 13, 2025 at 02:06:39PM +0530, Deepanshu Kartikey wrote:
> When laptop_mode is enabled, may_writepage is set to 0 in
> try_to_free_mem_cgroup_pages(). This triggers a warning in MGLRU's
> lru_gen_shrink_lruvec():
> 
>     VM_WARN_ON_ONCE(!sc->may_writepage || !sc->may_unmap);
> 
> The warning occurs because MGLRU expects full reclaim capabilities to
> function correctly. The call path is:
> 
>     mem_cgroup_resize_max()
>       try_to_free_mem_cgroup_pages()
>         do_try_to_free_pages()
>           shrink_node()
>             shrink_lruvec()
>               lru_gen_shrink_lruvec()  <-- WARNING
> 
> Unlike kswapd or direct reclaim where laptop_mode's disk-saving behavior
> is a reasonable optimization, memcg limit enforcement is a hard
> requirement - memory MUST be freed when a cgroup exceeds its limit.

That reasoning doesn't make sense to me. Reclaim is always in response
to an allocation need. The laptop_mode idea applies to cgroup reclaim
as much as any other reclaim.

Now obviously all of this is pretty dated. Reclaim doesn't do
filesystem writes anymore, and I'm not sure there are a whole lot of
laptops with rotational drives left, either. Also I doubt anybody is
still using zone_reclaim_mode (which is where the may_unmap is from).

But let's not introduce more inconsistencies, please. The only thing
weird here is the MGLRU warning. What is it trying to assert? Clearly
whatever assumption was made here has never been true.

And what is the zone_reclaim_mode (may_unmap) assert doing in the
cgroup limit reclaim path?

It seems to me both the warning in cgroup reclaim, and the goto done
in root reclaim, are kind of unnecessary and gratuitously breaking
both laptop_mode and zone_reclaim_mode - obsolete as they may be. But
why even add this code?

Can somebody with MGLRU context please take a look whether we can
remove these?

> Set may_writepage unconditionally to 1 for memcg reclaim to ensure
> MGLRU works correctly and memory limits are properly enforced.
> 
> Fixes: bd74fdaea146 ("mm: multi-gen LRU: support page table walks")

That seems unrelated?