All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhenhua Huang <quic_zhenhuah@quicinc.com>
To: Michal Hocko <mhocko@suse.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: Wed, 21 Sep 2022 16:18:56 +0800	[thread overview]
Message-ID: <4c4944d7-b690-a8ba-5d93-cbd09b5a28ca@quicinc.com> (raw)
In-Reply-To: <Yymh6Pkem2oQWyR9@dhcp22.suse.cz>

Thanks Michal again!

On 2022/9/20 19:20, Michal Hocko wrote:
> 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.

Thanks for your kind sharing between reclaim VS compaction for high 
order allocations, Michal. Now I agreed with Mel and you, compaction 
should play a more important role in this.. or we have to use CMA instead.

Thanks,
Zhenhua


      reply	other threads:[~2022-09-21  8:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-19  3:00 [RESEND PATCH] mm:page_alloc.c: lower the order requirement of should_reclaim_retry 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
2022-09-21  8:18           ` Zhenhua 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=4c4944d7-b690-a8ba-5d93-cbd09b5a28ca@quicinc.com \
    --to=quic_zhenhuah@quicinc.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=quic_tingweiz@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.