Re: [RESEND PATCH] mm:page_alloc.c: lower the order requirement of should_reclaim_retry

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux