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

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

[zhaoyang.huang]

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().

Suggested-by: T.J.Mercier <tjmercier@google.com>
Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
---
 mm/vmscan.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 670fe9fae5ba..9d900be478ea 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4832,10 +4832,6 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc)
 	int i;
 	enum zone_watermarks mark;
 
-	/* don't abort memcg reclaim to ensure fairness */
-	if (!root_reclaim(sc))
-		return false;
-
 	if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order)))
 		return true;
 
-- 
2.25.1

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

[T.J. Mercier]

On Wed, Feb 11, 2026 at 7:22 PM zhaoyang.huang
<zhaoyang.huang@unisoc.com> 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().
>
> Suggested-by: T.J.Mercier <tjmercier@google.com>
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>

Reviewed-by: T.J. Mercier <tjmercier@google.com>

Thanks!

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

[Michal Hocko]

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? Why doesn't our standard over-reclaim
protection work?

> Suggested-by: T.J.Mercier <tjmercier@google.com>
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> ---
>  mm/vmscan.c | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 670fe9fae5ba..9d900be478ea 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4832,10 +4832,6 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc)
>  	int i;
>  	enum zone_watermarks mark;
>  
> -	/* don't abort memcg reclaim to ensure fairness */
> -	if (!root_reclaim(sc))
> -		return false;
> -
>  	if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order)))
>  		return true;
>  
> -- 
> 2.25.1
> 

-- 
Michal Hocko
SUSE Labs

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

[T.J. Mercier]

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.

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

[Zhaoyang Huang]

On Tue, Mar 17, 2026 at 4:02 AM 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? Why doesn't our standard over-reclaim
> protection work?
Here is a previous test log which shows a nr_to_reclaim=32 pages
proactive reclaim ended with nr_reclaimed=394. T.J has explained the
reason for no limit over nr_reclaimed when !root_reclaim happens.

[  485.100981] sc ffffffc08b963ba8 memcg iter ffffff8086535a00
nr_to_reclaim 32 nr_reclaimed 0
[  485.106927] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff8086535a00 nr_to_reclaim 32 nr_reclaimed 127
[  485.109652] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff80744e1400 nr_to_reclaim 32 nr_reclaimed 127
[  485.112255] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff80744e4600 nr_to_reclaim 32 nr_reclaimed 127
[  485.115766] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff8150306e00 nr_to_reclaim 32 nr_reclaimed 191
[  485.125635] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff8157608a00 nr_to_reclaim 32 nr_reclaimed 191
[  485.131366] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff8157754600 nr_to_reclaim 32 nr_reclaimed 216
[  485.136688] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff8157752800 nr_to_reclaim 32 nr_reclaimed 216
[  485.140495] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff8157755000 nr_to_reclaim 32 nr_reclaimed 216
[  485.147322] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff8159461400 nr_to_reclaim 32 nr_reclaimed 216
[  485.150605] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff8159466400 nr_to_reclaim 32 nr_reclaimed 216
[  485.158260] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff8159460a00 nr_to_reclaim 32 nr_reclaimed 216
[  485.160819] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff8159460000 nr_to_reclaim 32 nr_reclaimed 216
[  485.163200] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff8159463c00 nr_to_reclaim 32 nr_reclaimed 216
[  485.171778] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff808912ee00 nr_to_reclaim 32 nr_reclaimed 216
[  485.174156] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff808912a800 nr_to_reclaim 32 nr_reclaimed 216
[  485.179110] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff814bd3a800 nr_to_reclaim 32 nr_reclaimed 216
[  485.181537] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff814bd39e00 nr_to_reclaim 32 nr_reclaimed 216
[  485.184877] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff814bd3da00 nr_to_reclaim 32 nr_reclaimed 219
[  485.187245] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff814bd38a00 nr_to_reclaim 32 nr_reclaimed 219
[  485.189654] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff814bd38000 nr_to_reclaim 32 nr_reclaimed 219
[  485.192029] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff814bd3bc00 nr_to_reclaim 32 nr_reclaimed 219
[  485.194509] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff814bd39400 nr_to_reclaim 32 nr_reclaimed 283
[  485.197107] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff814bd3c600 nr_to_reclaim 32 nr_reclaimed 330
[  485.201361] sc ffffffc08b963ba8 target_memcg ffffff8086535a00 memcg
iter ffffff814bd3ee00 nr_to_reclaim 32 nr_reclaimed 394

>
> > Suggested-by: T.J.Mercier <tjmercier@google.com>
> > Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> > ---
> >  mm/vmscan.c | 4 ----
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 670fe9fae5ba..9d900be478ea 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -4832,10 +4832,6 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc)
> >       int i;
> >       enum zone_watermarks mark;
> >
> > -     /* don't abort memcg reclaim to ensure fairness */
> > -     if (!root_reclaim(sc))
> > -             return false;
> > -
> >       if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order)))
> >               return true;
> >
> > --
> > 2.25.1
> >
>
> --
> Michal Hocko
> SUSE Labs

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

[Michal Hocko]

On Mon 16-03-26 14:09:52, T.J. Mercier wrote:
> 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.

OK, this describes the underlying problem much better. It should go into
the changelog. Including an explanation why MGLRU cannot follow the
traditional reclaim bail out logic.

Thanks!
-- 
Michal Hocko
SUSE Labs

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

[Zhaoyang Huang]

On Tue, Mar 17, 2026 at 3:52 PM Michal Hocko <mhocko@suse.com> wrote:
>
> On Mon 16-03-26 14:09:52, T.J. Mercier wrote:
> > 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.
>
> OK, this describes the underlying problem much better. It should go into
> the changelog. Including an explanation why MGLRU cannot follow the
> traditional reclaim bail out logic.
Patchv2 sent with commit message update. Thanks
>
> Thanks!
> --
> Michal Hocko
> SUSE Labs