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

[Michal Hocko]

On Sun 14-12-25 23:12:00, Johannes Weiner wrote:
> 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.

Completely agreed. This patch seems to just paper over a warning that
seems dubious while doing something that doesn't make much sense in
itself. Dropping laptop_mode from the memory reclaim seems like the
right direction anyway. I seriously doubt that it makes any practical or
measurable difference even on slow rotating storage laptops these days.

-- 
Michal Hocko
SUSE Labs