From: Michal Hocko <mhocko@suse.com>
To: Zhenhua Huang <quic_zhenhuah@quicinc.com>
Cc: akpm@linux-foundation.org, mgorman@techsingularity.net,
vbabka@suse.cz, linux-mm@kvack.org, quic_tingweiz@quicinc.com
Subject: Re: [RESEND PATCH] mm:page_alloc.c: lower the order requirement of should_reclaim_retry
Date: Tue, 20 Sep 2022 13:20:08 +0200 [thread overview]
Message-ID: <Yymh6Pkem2oQWyR9@dhcp22.suse.cz> (raw)
In-Reply-To: <f6e03e2f-bef8-ff11-79ef-88657556bfb0@quicinc.com>
On Tue 20-09-22 17:38:30, Zhenhua Huang wrote:
[...]
> > > > Also this patch doesn't really explain why it should work and honestly
> > > > it doesn't really make much sense to me either.
> > > Sorry, my fault. IMO, The reason it should work is, say for this case of
> > > order 3 allocation: we can perform direct reclaim more times as we have only
> > > order 2 pages(which *lowered* by this change) in free_list(8214*16kB (UEC)).
> > > The order requirement which I have lowered is should_reclaim_retry ->
> > > __zone_watermark_ok:
> > > for (o = order; o < MAX_ORDER; o++) {
> > > struct free_area *area = &z->free_area[o];
> > > ...
> > > for (mt = 0; mt < MIGRATE_PCPTYPES; mt++) {
> > > if (!free_area_empty(area, mt))
> > > return true;
> > > }
> > >
> > > Order 2 pages can be more easily met, hence VM has more chance to return
> > > true from should_reclaim_retry.
> >
> > This is a wrong approach to the problem because there is no real
> > guarantee the reclaim round will do anything useful. You should be
> > really looking at the compaction side of the thing.
>
> Thanks Michal for the advice, I'll look at from compaction side also. But I
> have one further question, IMO reclaim(~2GB LRU pages can be reclaimed)
> should be more feasible compared to compaction(already tried with highest
> prio and failed) in this case? Could you please elaborate more...it seems I
> still not fully understand why it's a wrong approach to check from reclaim
> phase.
Mel, has explained a large part I would go with let me just be more
explicit about one part. Memory reclaim is not order aware and that
means that probability of higher order pages are not directly related to
the number of reclaimed pages. You might be lucky and reclaim a THP to
form many order-3 pages or just reclaim those few that would create one
order-3 but all that is very unpredictable and hence we rely on the
compaction. Memory reclaim mostly assists compaction to allow some spare
memory to do the migration.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2022-09-20 11:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-19 3:00 Zhenhua Huang
2022-09-19 8:14 ` Michal Hocko
2022-09-19 11:24 ` Zhenhua Huang
2022-09-19 13:28 ` Michal Hocko
2022-09-20 9:38 ` Zhenhua Huang
2022-09-20 11:02 ` Mel Gorman
2022-09-21 8:12 ` Zhenhua Huang
2022-09-20 11:20 ` Michal Hocko [this message]
2022-09-21 8:18 ` Zhenhua Huang
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=Yymh6Pkem2oQWyR9@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=quic_tingweiz@quicinc.com \
--cc=quic_zhenhuah@quicinc.com \
--cc=vbabka@suse.cz \
/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