Re: [00/45 RFC PATCH] 1GB superpageblock memory allocation

[Rik van Riel]

On Fri, 2026-05-01 at 09:14 +0200, David Hildenbrand (Arm) wrote:
> On 4/30/26 22:20, Rik van Riel wrote:
> 
> Is there some text missing here, given that the first paragraph
> starts with
> "Neither of those" and I am not sure which solutions you have in
> mind?

Yeah, sorry. I suspect what may have happened is I
failed to leave a blank line between the email
headers and the first paragraph when I inserted the
file into the send-email compose.

Here's the first paragraph:

Some workloads see real performance benefits from using 1GB pages,
but allocating 1GB pages has often been limited to hugetlb pages
that were set aside at boot time, or using CMA to keep a fixed
amount of system memory off limits to the kernel.

> 
> > Neither of those are great solutions, given that modern servers
> > tend to be large, often run multiple workloads simultaneously,
> > and each workload wants something else.
> > 
> > To address that issue, this patch series divides memory not just
> > into 2MB page blocks, but into PUD sized superpageblocks, and
> > aggressively tries to steer unmovable, reclaimable, and highatomic
> > allocations into those superpageblocks that have already been
> > "tainted" by such allocations.
> 
> 
> Also, I know this series still needs a lot of
work. I will try to get many of those things out
of the way over the next few weeks.

Right now this mostly serves as an illustration
that reliable 1GB page allocation can be done.

Hopefully the next version will be more worthy 
of reviewer time.


-- 
All Rights Reversed.