linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zhaoyang Huang <huangzhaoyang@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: "zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Yu Zhao <yuzhao@google.com>, Rik van Riel <riel@surriel.com>,
	 Shakeel Butt <shakeel.butt@linux.dev>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	 Johannes Weiner <hannes@cmpxchg.org>,
	"T . J . Mercier" <tjmercier@google.com>,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org,
	steve.kang@unisoc.com
Subject: Re: [PATCH] mm: remove '!root_reclaim' checking in should_abort_scan()
Date: Tue, 17 Mar 2026 14:43:44 +0800	[thread overview]
Message-ID: <CAGWkznF1oVLvY6UwCGZShfoikmAQ27juuDeowiHLvv8acR4cZw@mail.gmail.com> (raw)
In-Reply-To: <abhh3lKb6med1LSp@tiehlicka>

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


      parent reply	other threads:[~2026-03-17  6:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-12  3:21 zhaoyang.huang
2026-02-12 22:57 ` T.J. Mercier
2026-03-16 20:02 ` Michal Hocko
2026-03-16 21:09   ` T.J. Mercier
2026-03-17  7:52     ` Michal Hocko
2026-03-17 12:32       ` Zhaoyang Huang
2026-03-17  6:43   ` Zhaoyang Huang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGWkznF1oVLvY6UwCGZShfoikmAQ27juuDeowiHLvv8acR4cZw@mail.gmail.com \
    --to=huangzhaoyang@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=riel@surriel.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=steve.kang@unisoc.com \
    --cc=tjmercier@google.com \
    --cc=yuzhao@google.com \
    --cc=zhaoyang.huang@unisoc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox