Re: [PATCH] mm: remove '!root_reclaim' checking in should_abort_scan()

["T.J. Mercier" <tjmercier@google.com>]

On Mon, Mar 16, 2026 at 1:02 PM Michal Hocko <mhocko@suse.com> wrote:
>
> On Thu 12-02-26 11:21:11, zhaoyang.huang wrote:
> > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> >
> > Nowadays, ANDROID system replaces madivse with memory.reclaim to implement
> > user space memory management which desires to reclaim a certain amount of
> > memcg's memory. However, oversized reclaiming and high latency are observed
> > as there is no limitation over nr_reclaimed inside try_to_shrink_lruvec
> > when MGLRU enabled. Besides, this could also affect all none root_reclaim
> > such as reclaim_high etc.
> > Since the commit 'b82b530740b9' ("mm: vmscan: restore incremental cgroup
> > iteration") introduces sc->memcg_full_walk to limit the walk range of
> > mem_cgroup_iter and keep the fairness among the descendants of one memcg.
> > This commit would like to make single memcg's scanning more precised by
> > removing the criteria of 'if (!root_reclaim)' inside
> > should_abort_scan().
>
> This changelog, similar to its previous version is lacking details on
> what exactly is going on. How much over-reclaim are we talking about
> here? Is this MGLRU specific?

Hi Michal,

This came from https://lore.kernel.org/all/20260210054312.303129-1-zhaoyang.huang@unisoc.com/

Zhaoyang would have to provide numbers, but yes this is MGLRU specific.

> Why doesn't our standard over-reclaim
> protection work?

"there is no limitation over nr_reclaimed inside try_to_shrink_lruvec"
This means that for proactive reclaim the check for sc->nr_reclaimed
>= sc->nr_to_reclaim is skipped, because the !root_reclaim(sc)
condition is hit first. So we never abort based on the value of
sc->nr_reclaimed, which can lead to overreclaim.

For try_to_free_mem_cgroup_pages -> shrink_node_memcgs ->
shrink_lruvec -> lru_gen_shrink_lruvec -> try_to_shrink_lruvec, the
!root_reclaim(sc) check was there for reclaim fairness, which was
necessary before commit 'b82b530740b9' ("mm: vmscan: restore
incremental cgroup iteration") because the fairness depended on
attempted proportional reclaim from every memcg under the target
memcg. However after commit 'b82b530740b9' there is no longer a need
to visit every memcg to ensure fairness, horray. The problem is for
large lruvecs, the lack of a check against sc->nr_to_reclaim inside
try_to_shrink_lruvec (caused by the continued presence of the
!root_reclaim(sc) check) can cause overreclaim. The non-MGLRU
implementation in shrink_lruvec already checks nr_reclaimed against
nr_to_reclaim.

Thanks,
T.J.