On 2/21/24 23:15, Andrew Morton wrote: > On Mon, 19 Feb 2024 10:55:59 +0800 Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx> wrote: >> >> >>> Signed-off-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx> >> >> >> >> I doubt this will make much difference, because if such a larger order free >> >> page exists, we shouldn't have a reason to be compacting for a lower order >> >> in the first place? >> > >> > Unless kswapd gets us such a free block in the background right after >> > get_page_from_freelist() and before compaction finishes in the allocation >> > slow path. >> > >> > If this happens often and cc->order is not -1, it might be better to stop >> > compaction and get_page_from_freelist() to save cycles on unnecessary pfn >> > scanning. For completeness, when cc->order == -1, the logic does not change. >> >> Yes, this is one possible case. There are also some other concurrent >> scenarios, such as when compaction is running (after >> compaction_suitable()), at the same time, other applications release a >> large folio to the free list. In this case, the free large folio >> scanning should also be avoided. > > This went quiet. > > We have an ack from Mel. Are people OK with sending this change > upstream? It's not wrong, so I'm OK.
