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

[Zhenhua Huang <quic_zhenhuah@quicinc.com>]

Thanks Mel for your detailed comments!

On 2022/9/20 19:02, Mel Gorman wrote:
> On Tue, Sep 20, 2022 at 05:38:30PM +0800, 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.
>>
> 
> Because it risks major slowdowns due to excessive reclaim. Early support
> used "lumpy reclaim" instead of compaction and resulted in major stalls when
> trying to allocate THP resulting in THP often being disabled. The success
> rates were great but systems could become unusable for several minutes
> and ultimately this resulted in compaction and the current backoff logic
> of reclaim. Your scenario is similar, you want to aggressively trying to
> shrink slabs in case an order-3 block of pages gets freed. It might succeed
> but the system grinds to a halt with excessive re-reading of information
> from the disk for other use cases.

Thanks, I've also noticed. Contiguous reclaim obviously enlarged the 
time to OOM as I saw.
> 
> Your focus likely should be on reclaim and compaction aborting
> prematurely because free CMA pages are available at the correct order
> but the calling context cannot use CMA pages.
> 
> It's strange to hear of a driver that has a strict need for order-3 pages
> being available at all times due to a lack of an IOMMU because that is
> going to be fragile. One point of CMA was to carve out a region for such
> drivers so they could the contiguous regions they needed. I believe phone
> cameras were an early example. If your driver has strict requirements for
> high-order page availability then CMA probably should be configured and
> the driver should use CMA.
> 

You point is to avoid to allocate order 3 unless that's really needed.
Got it, thanks.

Thanks,
Zhenhua