linux-kernel - Re: [PATCH] mm/compaction: do not break pages whose order is larger than target order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <D9J9VSOZ94HI.3RJWIYXWKZQS@nvidia.com>
Date: Tue, 29 Apr 2025 12:44:56 -0400
From: "Zi Yan" <ziy@...dia.com>
To: "Johannes Weiner" <hannes@...xchg.org>, "Wenchao Hao"
 <haowenchao22@...il.com>, "Baolin Wang" <baolin.wang@...ux.alibaba.com>
Cc: "Andrew Morton" <akpm@...ux-foundation.org>, <linux-mm@...ck.org>,
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm/compaction: do not break pages whose order is larger
 than target order

On Thu Apr 24, 2025 at 3:42 PM EDT, Johannes Weiner wrote:
> On Thu, Apr 24, 2025 at 11:38:15PM +0800, Wenchao Hao wrote:
>> When scanning free pages for memory compaction, if the compaction target
>> order is explicitly specified, do not split pages in buddy whose order
>> are larger than compaction target order.

If such a free page exist, why is the compaction triggered? I assume
buddy allocator would use the free page for allocation.

I see your email to Baolin mentioning it is about proactive compaction.
In that scenario, the order is -1 and the added code does not apply,
right?

>
> Have you observed this to be an issue in practice?

I wonder the same.

The free pages are kept in cc.freepages list at its order.
compaction_alloc() tries to use a page with the smallest order from the
list to avoid split a large order free page. But if no small free pages
are available, compaction_alloc() will split a large free page to make
compaction going.

But what I do not understand is that if there is a free page with order
greater than cc->order, why didn't buddy allocator use it for
allocation?

>
> compact_finished() would have bailed if such a page had existed.
>
> compaction_capture() would steal such a page upon production.
>
> It could help with blocks freed by chance from somewhere else, where
> you'd preserve it to grab it later from the allocation retry. But if
> that's the target, it might be better to indeed isolate the page, and
> then capture it inside compaction_alloc()?

-- 
Best Regards,
Yan, Zi