64k (or 16k) base page size on x86

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

Quoted 7 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

Quoted 5 lines

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

Didn't AA do this a decade ago or somesuch?

Quoted 10 lines · Peter Zijlstra

Quoted 9 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

Quoted 5 lines

Quoted 3 lines

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

Didn't AA do this a decade ago or somesuch?

https://lwn.net/Articles/240914/

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.

Potential benefits of the approach (assuming 64k pages):

- The order-0 page size cuts struct page overhead by a factor of 16. From

    ~1.6% of RAM to ~0.1%;

- TLB wins on machines with TLB coalescing as long as mapping is naturally

    aligned;

- Order-5 allocation is 2M, resulting in less pressure on the zone lock;

- 1G pages are within possibility for the buddy allocator - order-14 allocation. It can open the road to 1G THPs.

- As with THP, fewer pages - less pressure on the LRU lock;

Quoted 9 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

Quoted 4 lines

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

Doesn't this idea make less sense these days, with mTHP? Simply by toggling one of the entries in /sys/kernel/mm/transparent_hugepage.

Quoted 13 lines

The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.

Potential benefits of the approach (assuming 64k pages):

- The order-0 page size cuts struct page overhead by a factor of 16. From

    ~1.6% of RAM to ~0.1%;

- TLB wins on machines with TLB coalescing as long as mapping is naturally

    aligned;

- Order-5 allocation is 2M, resulting in less pressure on the zone lock;

Quoted 4 lines

- 1G pages are within possibility for the buddy allocator - order-14 allocation. It can open the road to 1G THPs.

- As with THP, fewer pages - less pressure on the LRU lock;

We could perhaps add a way to enforce a min_order globally on the page cache, as a way to address it.

There are some points there which aren't addressed by mTHP work in any way (1G THPs for one), others which are being addressed separately (memdesc work trying to cut down on struct page overhead).

(I also don't understand your point about order-5 allocation, AFAIK pcp will cache up to COSTLY_ORDER (3) and PMD order, but I'm probably not seeing the full picture)

Quoted 10 lines · Pedro Falcato

Quoted 9 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

Quoted 7 lines

Quoted 4 lines

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

Doesn't this idea make less sense these days, with mTHP? Simply by toggling one of the entries in /sys/kernel/mm/transparent_hugepage.

mTHP is still best effort. This is way you don't need to care about fragmentation, you will get your 64k page as long as you have free memory.

Quoted 13 lines

Quoted 13 lines

The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.

Potential benefits of the approach (assuming 64k pages):

- The order-0 page size cuts struct page overhead by a factor of 16. From

     ~1.6% of RAM to ~0.1%;

- TLB wins on machines with TLB coalescing as long as mapping is naturally

     aligned;

- Order-5 allocation is 2M, resulting in less pressure on the zone lock;

Quoted 7 lines

Quoted 4 lines

- 1G pages are within possibility for the buddy allocator - order-14 allocation. It can open the road to 1G THPs.

- As with THP, fewer pages - less pressure on the LRU lock;

We could perhaps add a way to enforce a min_order globally on the page cache, as a way to address it.

Raising min_order is not free. I puts more pressure on page allocator.

Quoted 4 lines

There are some points there which aren't addressed by mTHP work in any way (1G THPs for one), others which are being addressed separately (memdesc work trying to cut down on struct page overhead).

Quoted 3 lines

(I also don't understand your point about order-5 allocation, AFAIK pcp will cache up to COSTLY_ORDER (3) and PMD order, but I'm probably not seeing the full picture)

With higher base page size, page allocator doesn't need to do as much work to merge/split buddy pages. So serving the same 2M as order-5 is cheaper than order-9.

Quoted 54 lines · Kiryl Shutsemau

Quoted 10 lines · Pedro Falcato

Quoted 9 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

Quoted 7 lines

Quoted 4 lines

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

Doesn't this idea make less sense these days, with mTHP? Simply by toggling one of the entries in /sys/kernel/mm/transparent_hugepage.

mTHP is still best effort. This is way you don't need to care about fragmentation, you will get your 64k page as long as you have free memory.

Quoted 13 lines

Quoted 13 lines

The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.

Potential benefits of the approach (assuming 64k pages):

- The order-0 page size cuts struct page overhead by a factor of 16. From

     ~1.6% of RAM to ~0.1%;

- TLB wins on machines with TLB coalescing as long as mapping is naturally

     aligned;

- Order-5 allocation is 2M, resulting in less pressure on the zone lock;

Quoted 7 lines

Quoted 4 lines

- 1G pages are within possibility for the buddy allocator - order-14 allocation. It can open the road to 1G THPs.

- As with THP, fewer pages - less pressure on the LRU lock;

We could perhaps add a way to enforce a min_order globally on the page cache, as a way to address it.

Raising min_order is not free. I puts more pressure on page allocator.

Quoted 7 lines

There are some points there which aren't addressed by mTHP work in any way (1G THPs for one), others which are being addressed separately (memdesc work trying to cut down on struct page overhead).

(I also don't understand your point about order-5 allocation, AFAIK pcp will cache up to COSTLY_ORDER (3) and PMD order, but I'm probably not seeing the full picture)

Quoted 3 lines

With higher base page size, page allocator doesn't need to do as much work to merge/split buddy pages. So serving the same 2M as order-5 is cheaper than order-9.

I think the idea is that if most of your allocations (anon + pagecache) are 64k instead of 4k, on average, you'll just naturally do less merging splitting.

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.

Potential benefits of the approach (assuming 64k pages):

- The order-0 page size cuts struct page overhead by a factor of 16. From

     ~1.6% of RAM to ~0.1%;

- TLB wins on machines with TLB coalescing as long as mapping is naturally

     aligned;

- Order-5 allocation is 2M, resulting in less pressure on the zone lock;

- 1G pages are within possibility for the buddy allocator - order-14 allocation. It can open the road to 1G THPs.

- As with THP, fewer pages - less pressure on the LRU lock;

- ...

The trade-off is memory waste (similar to what we have on architectures with native 64k pages today) and complexity, mostly in the core-MM code.

== Design considerations ==

I want to split PAGE_SIZE into two distinct values:

- PTE_SIZE defines the virtual address space granularity;

- PG_SIZE defines the size of the order-0 buddy allocation;

PAGE_SIZE is only defined if PTE_SIZE == PG_SIZE. It will flag which code requires conversion, and keep existing code working while conversion is in progress.

The same split happens for other page-related macros: mask, shift, alignment helpers, etc.

PFNs are in PTE_SIZE units.

The buddy allocator and page cache (as well as all I/O) operate in PG_SIZE units.

Userspace mappings are maintained with PTE_SIZE granularity. No ABI changes for userspace. But we might want to communicate PG_SIZE to userspace to get the optimal results for userspace that cares.

PTE_SIZE granularity requires a substantial rework of page fault and VMA handling:

- A struct page pointer and pgprot_t are not enough to create a PTE entry. We also need the offset within the page we are creating the PTE for.

- Since the VMA start can be aligned arbitrarily with respect to the underlying page, vma->vm_pgoff has to be changed to vma->vm_pteoff, which is in PTE_SIZE units.

- The page fault handler needs to handle PTE_SIZE < PG_SIZE, including

     misaligned cases;

Page faults into file mappings are relatively simple to handle as we always have the page cache to refer to. So you can map only the part of the page that fits in the page table, similarly to fault-around.

Anonymous and file-CoW faults should also be simple as long as the VMA is aligned to PG_SIZE in both the virtual address space and with respect to vm_pgoff. We might waste some memory on the ends of the VMA, but it is tolerable.

Misaligned anonymous and file-CoW faults are a pain. Specifically, mapping pages across a page table boundary. In the worst case, a page is mapped across a PGD entry boundary and PTEs for the page have to be put in two separate subtrees of page tables.

A naive implementation would map different pages on different sides of a page table boundary and accept the waste of one page per page table crossing. The hope is that misaligned mappings are rare, but this is suboptimal.

mremap(2) is the ultimate stress test for the design.

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

Quoted 91 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.

Potential benefits of the approach (assuming 64k pages):

- The order-0 page size cuts struct page overhead by a factor of 16. From

     ~1.6% of RAM to ~0.1%;

- TLB wins on machines with TLB coalescing as long as mapping is naturally

     aligned;

- Order-5 allocation is 2M, resulting in less pressure on the zone lock;

- 1G pages are within possibility for the buddy allocator - order-14 allocation. It can open the road to 1G THPs.

- As with THP, fewer pages - less pressure on the LRU lock;

- ...

The trade-off is memory waste (similar to what we have on architectures with native 64k pages today) and complexity, mostly in the core-MM code.

== Design considerations ==

I want to split PAGE_SIZE into two distinct values:

- PTE_SIZE defines the virtual address space granularity;

- PG_SIZE defines the size of the order-0 buddy allocation;

PAGE_SIZE is only defined if PTE_SIZE == PG_SIZE. It will flag which code requires conversion, and keep existing code working while conversion is in progress.

The same split happens for other page-related macros: mask, shift, alignment helpers, etc.

PFNs are in PTE_SIZE units.

The buddy allocator and page cache (as well as all I/O) operate in PG_SIZE units.

Userspace mappings are maintained with PTE_SIZE granularity. No ABI changes for userspace. But we might want to communicate PG_SIZE to userspace to get the optimal results for userspace that cares.

PTE_SIZE granularity requires a substantial rework of page fault and VMA handling:

- A struct page pointer and pgprot_t are not enough to create a PTE entry. We also need the offset within the page we are creating the PTE for.

- Since the VMA start can be aligned arbitrarily with respect to the underlying page, vma->vm_pgoff has to be changed to vma->vm_pteoff, which is in PTE_SIZE units.

- The page fault handler needs to handle PTE_SIZE < PG_SIZE, including

     misaligned cases;

Page faults into file mappings are relatively simple to handle as we always have the page cache to refer to. So you can map only the part of the page that fits in the page table, similarly to fault-around.

Anonymous and file-CoW faults should also be simple as long as the VMA is aligned to PG_SIZE in both the virtual address space and with respect to vm_pgoff. We might waste some memory on the ends of the VMA, but it is tolerable.

Misaligned anonymous and file-CoW faults are a pain. Specifically, mapping pages across a page table boundary. In the worst case, a page is mapped across a PGD entry boundary and PTEs for the page have to be put in two separate subtrees of page tables.

A naive implementation would map different pages on different sides of a page table boundary and accept the waste of one page per page table crossing. The hope is that misaligned mappings are rare, but this is suboptimal.

Quoted 6 lines

mremap(2) is the ultimate stress test for the design.

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

When discussing per-process page sizes with Ryan and Dev, I mentioned that having a larger emulated page size could be interesting for other architectures as well.

That is, we would emulate a 64K page size on Intel for user space as well, but let the OS work with 4K pages.

We'd only allocate+map large folios into user space + pagecache, but still allow for page tables etc. to not waste memory.

So "most" of your allocations in the system would actually be at least 64k, reducing zone lock contention etc.

It doesn't solve all the problems you wanted to tackle on your list (e.g., "struct page" overhead, which will be sorted out by memdescs).

Quoted 109 lines · David Hildenbrand (Arm)

Quoted 91 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.

Potential benefits of the approach (assuming 64k pages):

- The order-0 page size cuts struct page overhead by a factor of 16. From ~1.6% of RAM to ~0.1%;

- TLB wins on machines with TLB coalescing as long as mapping is naturally aligned;

- Order-5 allocation is 2M, resulting in less pressure on the zone lock;

- 1G pages are within possibility for the buddy allocator - order-14 allocation. It can open the road to 1G THPs.

- As with THP, fewer pages - less pressure on the LRU lock;

- ...

The trade-off is memory waste (similar to what we have on architectures with native 64k pages today) and complexity, mostly in the core-MM code.

== Design considerations ==

I want to split PAGE_SIZE into two distinct values:

- PTE_SIZE defines the virtual address space granularity;

- PG_SIZE defines the size of the order-0 buddy allocation;

PAGE_SIZE is only defined if PTE_SIZE == PG_SIZE. It will flag which code requires conversion, and keep existing code working while conversion is in progress.

The same split happens for other page-related macros: mask, shift, alignment helpers, etc.

PFNs are in PTE_SIZE units.

The buddy allocator and page cache (as well as all I/O) operate in PG_SIZE units.

Userspace mappings are maintained with PTE_SIZE granularity. No ABI changes for userspace. But we might want to communicate PG_SIZE to userspace to get the optimal results for userspace that cares.

PTE_SIZE granularity requires a substantial rework of page fault and VMA handling:

- A struct page pointer and pgprot_t are not enough to create a PTE entry. We also need the offset within the page we are creating the PTE for.

- Since the VMA start can be aligned arbitrarily with respect to the underlying page, vma->vm_pgoff has to be changed to vma->vm_pteoff, which is in PTE_SIZE units.

- The page fault handler needs to handle PTE_SIZE < PG_SIZE, including misaligned cases;

Page faults into file mappings are relatively simple to handle as we always have the page cache to refer to. So you can map only the part of the page that fits in the page table, similarly to fault-around.

Anonymous and file-CoW faults should also be simple as long as the VMA is aligned to PG_SIZE in both the virtual address space and with respect to vm_pgoff. We might waste some memory on the ends of the VMA, but it is tolerable.

Misaligned anonymous and file-CoW faults are a pain. Specifically, mapping pages across a page table boundary. In the worst case, a page is mapped across a PGD entry boundary and PTEs for the page have to be put in two separate subtrees of page tables.

A naive implementation would map different pages on different sides of a page table boundary and accept the waste of one page per page table crossing. The hope is that misaligned mappings are rare, but this is suboptimal.

Quoted 6 lines

mremap(2) is the ultimate stress test for the design.

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

When discussing per-process page sizes with Ryan and Dev, I mentioned that having a larger emulated page size could be interesting for other architectures as well.

That is, we would emulate a 64K page size on Intel for user space as well, but let the OS work with 4K pages.

We'd only allocate+map large folios into user space + pagecache, but still allow for page tables etc. to not waste memory.

Quoted 2 lines

So "most" of your allocations in the system would actually be at least 64k, reducing zone lock contention etc.

I am not convinced emulation would help zone lock contention. I expect contention to be higher if page allocator would see a mix of 4k and 64k requests. It sounds like constant split/merge under the lock.

Quoted 3 lines

It doesn't solve all the problems you wanted to tackle on your list (e.g., "struct page" overhead, which will be sorted out by memdescs).

I don't think we can serve 1G pages out of buddy allocator with 4k order-0. And without it, I don't see how to get to a viable 1G THPs.

Quoted 110 lines · Kiryl Shutsemau

Quoted 109 lines · David Hildenbrand (Arm)

Quoted 91 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.

Potential benefits of the approach (assuming 64k pages):

- The order-0 page size cuts struct page overhead by a factor of 16. From ~1.6% of RAM to ~0.1%;

- TLB wins on machines with TLB coalescing as long as mapping is naturally aligned;

- Order-5 allocation is 2M, resulting in less pressure on the zone lock;

- 1G pages are within possibility for the buddy allocator - order-14 allocation. It can open the road to 1G THPs.

- As with THP, fewer pages - less pressure on the LRU lock;

- ...

The trade-off is memory waste (similar to what we have on architectures with native 64k pages today) and complexity, mostly in the core-MM code.

== Design considerations ==

I want to split PAGE_SIZE into two distinct values:

- PTE_SIZE defines the virtual address space granularity;

- PG_SIZE defines the size of the order-0 buddy allocation;

PAGE_SIZE is only defined if PTE_SIZE == PG_SIZE. It will flag which code requires conversion, and keep existing code working while conversion is in progress.

The same split happens for other page-related macros: mask, shift, alignment helpers, etc.

PFNs are in PTE_SIZE units.

The buddy allocator and page cache (as well as all I/O) operate in PG_SIZE units.

Userspace mappings are maintained with PTE_SIZE granularity. No ABI changes for userspace. But we might want to communicate PG_SIZE to userspace to get the optimal results for userspace that cares.

PTE_SIZE granularity requires a substantial rework of page fault and VMA handling:

- A struct page pointer and pgprot_t are not enough to create a PTE entry. We also need the offset within the page we are creating the PTE for.

- Since the VMA start can be aligned arbitrarily with respect to the underlying page, vma->vm_pgoff has to be changed to vma->vm_pteoff, which is in PTE_SIZE units.

- The page fault handler needs to handle PTE_SIZE < PG_SIZE, including misaligned cases;

Page faults into file mappings are relatively simple to handle as we always have the page cache to refer to. So you can map only the part of the page that fits in the page table, similarly to fault-around.

Anonymous and file-CoW faults should also be simple as long as the VMA is aligned to PG_SIZE in both the virtual address space and with respect to vm_pgoff. We might waste some memory on the ends of the VMA, but it is tolerable.

Misaligned anonymous and file-CoW faults are a pain. Specifically, mapping pages across a page table boundary. In the worst case, a page is mapped across a PGD entry boundary and PTEs for the page have to be put in two separate subtrees of page tables.

A naive implementation would map different pages on different sides of a page table boundary and accept the waste of one page per page table crossing. The hope is that misaligned mappings are rare, but this is suboptimal.

Quoted 6 lines

mremap(2) is the ultimate stress test for the design.

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

When discussing per-process page sizes with Ryan and Dev, I mentioned that having a larger emulated page size could be interesting for other architectures as well.

That is, we would emulate a 64K page size on Intel for user space as well, but let the OS work with 4K pages.

We'd only allocate+map large folios into user space + pagecache, but still allow for page tables etc. to not waste memory.

Quoted 6 lines

Quoted 2 lines

So "most" of your allocations in the system would actually be at least 64k, reducing zone lock contention etc.

I am not convinced emulation would help zone lock contention. I expect contention to be higher if page allocator would see a mix of 4k and 64k requests. It sounds like constant split/merge under the lock.

If most your allocations are larger, then there isn't that much splitting/merging.

There will be some for the < 64k allocations of course, but when all user space+page cache is >= 64 then the split/merge + zone lock should be heavily reduced.

Quoted 1 line

Quoted 5 lines

Quoted 2 lines

It doesn't solve all the problems you wanted to tackle on your list (e.g., "struct page" overhead, which will be sorted out by memdescs).

I don't think we can serve 1G pages out of buddy allocator with 4k order-0. And without it, I don't see how to get to a viable 1G THPs.

Zi Yan was one working on this, and I think we had ideas on how to make that work in the long run.

Quoted 9 lines

When discussing per-process page sizes with Ryan and Dev, I mentioned that having a larger emulated page size could be interesting for other architectures as well.
That is, we would emulate a 64K page size on Intel for user space as well, but let the OS work with 4K pages.
We'd only allocate+map large folios into user space + pagecache, but still allow for page tables etc. to not waste memory.
So "most" of your allocations in the system would actually be at least 64k, reducing zone lock contention etc.

I am not convinced emulation would help zone lock contention. I expect contention to be higher if page allocator would see a mix of 4k and 64k requests. It sounds like constant split/merge under the lock.

Quoted 2 lines

It doesn't solve all the problems you wanted to tackle on your list (e.g., "struct page" overhead, which will be sorted out by memdescs).

I don't think we can serve 1G pages out of buddy allocator with 4k order-0. And without it, I don't see how to get to a viable 1G THPs.

Quoted 91 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.

Potential benefits of the approach (assuming 64k pages):

- The order-0 page size cuts struct page overhead by a factor of 16. From

     ~1.6% of RAM to ~0.1%;

- TLB wins on machines with TLB coalescing as long as mapping is naturally

     aligned;

- Order-5 allocation is 2M, resulting in less pressure on the zone lock;

- 1G pages are within possibility for the buddy allocator - order-14 allocation. It can open the road to 1G THPs.

- As with THP, fewer pages - less pressure on the LRU lock;

- ...

The trade-off is memory waste (similar to what we have on architectures with native 64k pages today) and complexity, mostly in the core-MM code.

== Design considerations ==

I want to split PAGE_SIZE into two distinct values:

- PTE_SIZE defines the virtual address space granularity;

- PG_SIZE defines the size of the order-0 buddy allocation;

PAGE_SIZE is only defined if PTE_SIZE == PG_SIZE. It will flag which code requires conversion, and keep existing code working while conversion is in progress.

The same split happens for other page-related macros: mask, shift, alignment helpers, etc.

PFNs are in PTE_SIZE units.

The buddy allocator and page cache (as well as all I/O) operate in PG_SIZE units.

Userspace mappings are maintained with PTE_SIZE granularity. No ABI changes for userspace. But we might want to communicate PG_SIZE to userspace to get the optimal results for userspace that cares.

PTE_SIZE granularity requires a substantial rework of page fault and VMA handling:

- A struct page pointer and pgprot_t are not enough to create a PTE entry. We also need the offset within the page we are creating the PTE for.

- Since the VMA start can be aligned arbitrarily with respect to the underlying page, vma->vm_pgoff has to be changed to vma->vm_pteoff, which is in PTE_SIZE units.

- The page fault handler needs to handle PTE_SIZE < PG_SIZE, including

     misaligned cases;

Page faults into file mappings are relatively simple to handle as we always have the page cache to refer to. So you can map only the part of the page that fits in the page table, similarly to fault-around.

Anonymous and file-CoW faults should also be simple as long as the VMA is aligned to PG_SIZE in both the virtual address space and with respect to vm_pgoff. We might waste some memory on the ends of the VMA, but it is tolerable.

Misaligned anonymous and file-CoW faults are a pain. Specifically, mapping pages across a page table boundary. In the worst case, a page is mapped across a PGD entry boundary and PTEs for the page have to be put in two separate subtrees of page tables.

A naive implementation would map different pages on different sides of a page table boundary and accept the waste of one page per page table crossing. The hope is that misaligned mappings are rare, but this is suboptimal.

Quoted 6 lines

mremap(2) is the ultimate stress test for the design.

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

When discussing per-process page sizes with Ryan and Dev, I mentioned that having a larger emulated page size could be interesting for other architectures as well.

That is, we would emulate a 64K page size on Intel for user space as well, but let the OS work with 4K pages.

We'd only allocate+map large folios into user space + pagecache, but still allow for page tables etc. to not waste memory.

Quoted 6 lines

When discussing per-process page sizes with Ryan and Dev, I mentioned that having a larger emulated page size could be interesting for other architectures as well.

That is, we would emulate a 64K page size on Intel for user space as well, but let the OS work with 4K pages.

Just to clarify, do you want it to be enforced on userspace ABI. Like, all mappings are 64k aligned?

Quoted 3 lines

We'd only allocate+map large folios into user space + pagecache, but still allow for page tables etc. to not waste memory.

Waste of memory for page table is solvable and pretty straight forward. Most of such cases can be solve mechanically by switching to slab.

Quoted 7 lines

Quoted 6 lines

When discussing per-process page sizes with Ryan and Dev, I mentioned that having a larger emulated page size could be interesting for other architectures as well.

That is, we would emulate a 64K page size on Intel for user space as well, but let the OS work with 4K pages.

Quoted 2 lines

Just to clarify, do you want it to be enforced on userspace ABI. Like, all mappings are 64k aligned?

Right, see the proposal from Dev on the list.

From user-space POV, the pagesize would be 64K for these emulated processes. That is, VMAs must be suitable aligned etc.

Quoted 5 lines

Quoted 2 lines

We'd only allocate+map large folios into user space + pagecache, but still allow for page tables etc. to not waste memory.

Waste of memory for page table is solvable and pretty straight forward. Most of such cases can be solve mechanically by switching to slab.

Well, yes, like Willy says, there are already similar custom solutions for s390x and ppc.

Pasha talked recently about the memory waste of 16k kernel stacks and how we would want to reduce that to 4k. In your proposal, it would be 64k, unless you somehow manage to allocate multiple kernel stacks from the same 64k page. My head hurts thinking about whether that could work, maybe it could (no idea about guard pages in there, though).

Let's take a look at the history of page size usage on Arm (people can feel free to correct me):

(1) Most distros were using 64k on Arm.

(2) People realized that 64k was suboptimal many use cases (memory waste for stacks, pagecache, etc) and started to switch to 4k. I remember that mostly HPC-centric users sticked to 64k, but there was also demand from others to be able to stay on 64k.

(3) Arm improved performance on a 4k kernel by adding cont-pte support, trying to get closer to 64k native performance.

(4) Achieving 64k native performance is hard, which is why per-process page sizes are being explored to get the best out of both worlds (use 64k page size only where it really matters for performance).

Arm clearly has the added benefit of actually benefiting from hardware support for 64k.

IIUC, what you are proposing feels a bit like traveling back in time when it comes to the memory waste problem that Arm users encountered.

Where do you see the big difference to 64k on Arm in your proposal? Would you currently also be running 64k Arm in production and the memory waste etc is acceptable?

Quoted 4 lines · David Hildenbrand (Arm)

Quoted 3 lines

Just to clarify, do you want it to be enforced on userspace ABI. Like, all mappings are 64k aligned?

Quoted 4 lines

Right, see the proposal from Dev on the list.

From user-space POV, the pagesize would be 64K for these emulated processes.
That is, VMAs must be suitable aligned etc.

Well, it will drastically limit the adoption. We have too much legacy stuff on x86.

Quoted 8 lines

Quoted 4 lines

Waste of memory for page table is solvable and pretty straight forward. Most of such cases can be solve mechanically by switching to slab.

Well, yes, like Willy says, there are already similar custom solutions for s390x and ppc.

Quoted 5 lines

Pasha talked recently about the memory waste of 16k kernel stacks and how we would want to reduce that to 4k. In your proposal, it would be 64k, unless you somehow manage to allocate multiple kernel stacks from the same 64k page. My head hurts thinking about whether that could work, maybe it could (no idea about guard pages in there, though).

Kernel stack is allocated from vmalloc. I think mapping them with sub-page granularity should be doable.

BTW, do you see any reason why slab-allocated stack wouldn't work for large base page sizes? There's no requirement for it be aligned to page or PTE, right?

Quoted 21 lines

Let's take a look at the history of page size usage on Arm (people can feel free to correct me):

(1) Most distros were using 64k on Arm.

(2) People realized that 64k was suboptimal many use cases (memory waste for stacks, pagecache, etc) and started to switch to 4k. I remember that mostly HPC-centric users sticked to 64k, but there was also demand from others to be able to stay on 64k.

(3) Arm improved performance on a 4k kernel by adding cont-pte support, trying to get closer to 64k native performance.

(4) Achieving 64k native performance is hard, which is why per-process page sizes are being explored to get the best out of both worlds (use 64k page size only where it really matters for performance).

Arm clearly has the added benefit of actually benefiting from hardware support for 64k.

Quoted 6 lines

IIUC, what you are proposing feels a bit like traveling back in time when it comes to the memory waste problem that Arm users encountered.

Where do you see the big difference to 64k on Arm in your proposal? Would you currently also be running 64k Arm in production and the memory waste etc is acceptable?

That's the point. I don't see a big difference to 64k Arm. I want to bring this option to x86: at some machine size it makes sense trade memory consumption for scalability. I am targeting it to machines with over 2TiB of RAM.

BTW, we do run 64k Arm in our fleet. There's some growing pains, but it looks good in general We have no plans to switch to 4k (or 16k) at the moment. 512M THPs also look good on some workloads.

Quoted 10 lines · Kiryl Shutsemau

Quoted 8 lines · David Hildenbrand (Arm)

Quoted 3 lines

Just to clarify, do you want it to be enforced on userspace ABI. Like, all mappings are 64k aligned?

Right, see the proposal from Dev on the list.

From user-space POV, the pagesize would be 64K for these emulated processes.
That is, VMAs must be suitable aligned etc.

Quoted 2 lines

Well, it will drastically limit the adoption. We have too much legacy stuff on x86.

I'd assume that many applications nowadays can deal with differing page sizes (thanks to some other architectures paving the way).

But yes, some real legacy stuff, or stuff that ever only cared about intel still hardcodes pagesize=4k.

In Meta's fleet, I'd be quite interesting how much conversion there would have to be done.

For legacy apps, you could still run them as 4k pagesize on the same system, of course.

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

Waste of memory for page table is solvable and pretty straight forward. Most of such cases can be solve mechanically by switching to slab.

Well, yes, like Willy says, there are already similar custom solutions for s390x and ppc.

Quoted 8 lines

Quoted 5 lines

Pasha talked recently about the memory waste of 16k kernel stacks and how we would want to reduce that to 4k. In your proposal, it would be 64k, unless you somehow manage to allocate multiple kernel stacks from the same 64k page. My head hurts thinking about whether that could work, maybe it could (no idea about guard pages in there, though).

Kernel stack is allocated from vmalloc. I think mapping them with sub-page granularity should be doable.

I still have to wrap my head around the sub-page mapping here as well. It's scary.

Re mapcount: I think if any part of the page is mapped, it would be considered mapped -> mapcount += 1.

Quoted 4 lines

BTW, do you see any reason why slab-allocated stack wouldn't work for large base page sizes? There's no requirement for it be aligned to page or PTE, right?

I'd assume that would work. Devil is in the detail with these things before we have memdescs.

E.g., page table have a dedicated type (PGTY_table) and store separate metadata in the ptdesc. For kernel stack there was once a proposal to have a type but it is not upstream.

Quoted 28 lines

Quoted 21 lines

Let's take a look at the history of page size usage on Arm (people can feel free to correct me):

(1) Most distros were using 64k on Arm.

(2) People realized that 64k was suboptimal many use cases (memory waste for stacks, pagecache, etc) and started to switch to 4k. I remember that mostly HPC-centric users sticked to 64k, but there was also demand from others to be able to stay on 64k.

(3) Arm improved performance on a 4k kernel by adding cont-pte support, trying to get closer to 64k native performance.

(4) Achieving 64k native performance is hard, which is why per-process page sizes are being explored to get the best out of both worlds (use 64k page size only where it really matters for performance).

Arm clearly has the added benefit of actually benefiting from hardware support for 64k.

Quoted 6 lines

IIUC, what you are proposing feels a bit like traveling back in time when it comes to the memory waste problem that Arm users encountered.

Where do you see the big difference to 64k on Arm in your proposal? Would you currently also be running 64k Arm in production and the memory waste etc is acceptable?

Quoted 8 lines

That's the point. I don't see a big difference to 64k Arm. I want to bring this option to x86: at some machine size it makes sense trade memory consumption for scalability. I am targeting it to machines with over 2TiB of RAM.

BTW, we do run 64k Arm in our fleet. There's some growing pains, but it looks good in general We have no plans to switch to 4k (or 16k) at the moment. 512M THPs also look good on some workloads.

Okay, that's valuable information, thanks!

Being able to remove the sub-page mapping part (or being able to just hide it somewhere deep down in arch code) would make this a lot easier to digest.

--
Cheers,

David

Quoted 9 lines · David Hildenbrand (Arm)

Quoted 3 lines · Kiryl Shutsemau

Well, it will drastically limit the adoption. We have too much legacy stuff on x86.

I'd assume that many applications nowadays can deal with differing page sizes (thanks to some other architectures paving the way).

Quoted 2 lines

But yes, some real legacy stuff, or stuff that ever only cared about intel still hardcodes pagesize=4k.

I think most issues will stem from linkers setting the default ELF segment alignment (max-page-size) for x86 to 4096. So those ELFs will not load correctly or at all on the larger emulated granularity.

Quoted 14 lines · Kalesh Singh

Quoted 11 lines · David Hildenbrand (Arm)

Quoted 3 lines · Kiryl Shutsemau

Well, it will drastically limit the adoption. We have too much legacy stuff on x86.

I'd assume that many applications nowadays can deal with differing page sizes (thanks to some other architectures paving the way).

But yes, some real legacy stuff, or stuff that ever only cared about intel still hardcodes pagesize=4k.

Quoted 3 lines

I think most issues will stem from linkers setting the default ELF segment alignment (max-page-size) for x86 to 4096. So those ELFs will not load correctly or at all on the larger emulated granularity.

Right, I assume that they will have to be thought about that, and possibly, some binaries/libraries recompiled.

Quoted 10 lines · David Hildenbrand (Arm)

Quoted 6 lines · Kalesh Singh

On Fri, Feb 20, 2026 at 8:30 AM David Hildenbrand (Arm) <[email protected]> wrote:

I think most issues will stem from linkers setting the default ELF segment alignment (max-page-size) for x86 to 4096. So those ELFs will not load correctly or at all on the larger emulated granularity.

Right, I assume that they will have to be thought about that, and possibly, some binaries/libraries recompiled.

I think backward compatibility is important and I believe we can get there without ABI break. And optimize from there.

BTW, x86-64 SysV ABI allows for 64k page size:

Systems are permitted to use any power-of-two page size between 4KB and 64KB, inclusive.

But it doesn't work in practice.

Quoted 15 lines · Kiryl Shutsemau

Quoted 10 lines · David Hildenbrand (Arm)

Quoted 6 lines · Kalesh Singh

On Fri, Feb 20, 2026 at 8:30 AM David Hildenbrand (Arm) <[email protected]> wrote:

I think most issues will stem from linkers setting the default ELF segment alignment (max-page-size) for x86 to 4096. So those ELFs will not load correctly or at all on the larger emulated granularity.

Right, I assume that they will have to be thought about that, and possibly, some binaries/libraries recompiled.

I think backward compatibility is important and I believe we can get there without ABI break. And optimize from there.

Quoted 6 lines

BTW, x86-64 SysV ABI allows for 64k page size:

Systems are permitted to use any power-of-two page size between 4KB and 64KB, inclusive.

But it doesn't work in practice.

Even in well controlled environments you would run in a hyperscaler?

Quoted 6 lines

BTW, x86-64 SysV ABI allows for 64k page size:

    Systems are permitted to use any power-of-two page size between 4KB and 64KB, inclusive.

But it doesn't work in practice.

Even in well controlled environments you would run in a hyperscaler?

On 2/23/26 03:27, David Hildenbrand (Arm) wrote:
...

Quoted 2 lines

Quoted 2 lines

BTW, x86-64 SysV ABI allows for 64k page size:

Quoted 6 lines

Quoted 4 lines

    Systems are permitted to use any power-of-two page size between 4KB and 64KB, inclusive.

But it doesn't work in practice.

Even in well controlled environments you would run in a hyperscaler?

I think what Kirill is trying to say is that "it breaks userspace". ;)

A hyperscaler (or other "embedded" environment) might be willing or able to go fix up userspace breakage. I would suspect our high frequency trading friends would be all over this if it shaved a microsecond off their receive times.

The more important question is what it breaks and how badly it breaks things. 5-level paging, for instance, broke some JITs that historically used the new (>48) upper virtual address bits for metadata. The gains from 5-level paging were big enough and the userspace breakage was confined and fixable enough that 5-level paging was viable.

I'm not sure which side a larger base page side will fall on, though. Is it going to be an out-of-tree hack that a few folks use, or will it be more like 5-level paging and be good enough that it goes into mainline?

Quoted 4 lines · Dave Hansen

On 2/23/26 03:27, David Hildenbrand (Arm) wrote:
...

Quoted 2 lines

Quoted 2 lines

BTW, x86-64 SysV ABI allows for 64k page size:

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

    Systems are permitted to use any power-of-two page size between 4KB and 64KB, inclusive.

But it doesn't work in practice.

Even in well controlled environments you would run in a hyperscaler?

I think what Kirill is trying to say is that "it breaks userspace". ;)

Yes. Probably similar to Intel proposing an actual 64k page size. Expected. :)

Quoted 12 lines

A hyperscaler (or other "embedded" environment) might be willing or able to go fix up userspace breakage. I would suspect our high frequency trading friends would be all over this if it shaved a microsecond off their receive times.

The more important question is what it breaks and how badly it breaks things. 5-level paging, for instance, broke some JITs that historically used the new (>48) upper virtual address bits for metadata. The gains from 5-level paging were big enough and the userspace breakage was confined and fixable enough that 5-level paging was viable.

Quoted 3 lines

I'm not sure which side a larger base page side will fall on, though. Is it going to be an out-of-tree hack that a few folks use, or will it be more like 5-level paging and be good enough that it goes into mainline?

Just thinking about VMAs spanning partial pages makes me shiver. Or A single page spanning multiple VMAs.

I haven't seen the code yet, but I am certain that I will not like it.

I'm happy to be proven wrong :)

Quoted 3 lines

Just thinking about VMAs spanning partial pages makes me shiver. Or A single page spanning multiple VMAs.

Hate to break it to you, but we have it now upstream :P

THP can span multiple VMAs. And can be partially mapped.

Quoted 4 lines · Dave Hansen

On 2/23/26 03:27, David Hildenbrand (Arm) wrote:
...

Quoted 2 lines

Quoted 2 lines

BTW, x86-64 SysV ABI allows for 64k page size:

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

    Systems are permitted to use any power-of-two page size between 4KB and 64KB, inclusive.

But it doesn't work in practice.

Even in well controlled environments you would run in a hyperscaler?

I think what Kirill is trying to say is that "it breaks userspace". ;)

Yes. Probably similar to Intel proposing an actual 64k page size. Expected. :)

Quoted 12 lines

A hyperscaler (or other "embedded" environment) might be willing or able to go fix up userspace breakage. I would suspect our high frequency trading friends would be all over this if it shaved a microsecond off their receive times.

The more important question is what it breaks and how badly it breaks things. 5-level paging, for instance, broke some JITs that historically used the new (>48) upper virtual address bits for metadata. The gains from 5-level paging were big enough and the userspace breakage was confined and fixable enough that 5-level paging was viable.

Quoted 3 lines

I'm not sure which side a larger base page side will fall on, though. Is it going to be an out-of-tree hack that a few folks use, or will it be more like 5-level paging and be good enough that it goes into mainline?

Just thinking about VMAs spanning partial pages makes me shiver. Or A single page spanning multiple VMAs.

I haven't seen the code yet, but I am certain that I will not like it.

I'm happy to be proven wrong :)

--
Cheers,

David

On 2/23/26 03:27, David Hildenbrand (Arm) wrote:
...

Quoted 2 lines

Quoted 2 lines

BTW, x86-64 SysV ABI allows for 64k page size:

Quoted 6 lines

Quoted 4 lines

    Systems are permitted to use any power-of-two page size between 4KB and 64KB, inclusive.

But it doesn't work in practice.

Even in well controlled environments you would run in a hyperscaler?

I think what Kirill is trying to say is that "it breaks userspace". ;)

Right, see the proposal from Dev on the list.
From user-space POV, the pagesize would be 64K for these emulated processes. That is, VMAs must be suitable aligned etc.
One key thing I think is that you could run such emulated-64k process (that actually support it!) with 4k processes on the same machine, like Arm is considering.
You would have no weird "vma crosses base pages" handling, which is just rather nasty and makes my head hurt.

Well, yes, like Willy says, there are already similar custom solutions for s390x and ppc.
Pasha talked recently about the memory waste of 16k kernel stacks and how we would want to reduce that to 4k. In your proposal, it would be 64k, unless you somehow manage to allocate multiple kernel stacks from the same 64k page. My head hurts thinking about whether that could work, maybe it could (no idea about guard pages in there, though).

Let's take a look at the history of page size usage on Arm (people can feel free to correct me):
(1) Most distros were using 64k on Arm.
(2) People realized that 64k was suboptimal many use cases (memory

waste for stacks, pagecache, etc) and started to switch to 4k. I remember that mostly HPC-centric users sticked to 64k, but there was also demand from others to be able to stay on 64k.
(3) Arm improved performance on a 4k kernel by adding cont-pte support, trying to get closer to 64k native performance.
(4) Achieving 64k native performance is hard, which is why per-process page sizes are being explored to get the best out of both worlds (use 64k page size only where it really matters for performance).

Arm clearly has the added benefit of actually benefiting from hardware support for 64k.
IIUC, what you are proposing feels a bit like traveling back in time when it comes to the memory waste problem that Arm users encountered. Where do you see the big difference to 64k on Arm in your proposal? Would you currently also be running 64k Arm in production and the memory waste etc is acceptable?

Quoted 8 lines · David Hildenbrand (Arm)

Right, see the proposal from Dev on the list.
From user-space POV, the pagesize would be 64K for these emulated processes. That is, VMAs must be suitable aligned etc.
One key thing I think is that you could run such emulated-64k process (that actually support it!) with 4k processes on the same machine, like Arm is considering.
You would have no weird "vma crosses base pages" handling, which is just rather nasty and makes my head hurt.

While it had to be written, it was a straightforward extension of converting ->vm_pgoff to being in MMUPAGE_SIZE (Kiryl's PTE_SIZE) units, recovering offsets into pages usw. Nothing seemed terribly hard to understand about it. Really, the code as it stands rarely approaches what it's doing in such a way that it broadly surveys the layout of vmas and pages and be conscious of whether pages spanned vmas or multiple vmas were representing maps of of fragments of pages, so I'm not convinced there's anything particularly unique to be afraid of here.

Quoted 8 lines

While it had to be written, it was a straightforward extension of converting ->vm_pgoff to being in MMUPAGE_SIZE (Kiryl's PTE_SIZE) units, recovering offsets into pages usw. Nothing seemed terribly hard to understand about it. Really, the code as it stands rarely approaches what it's doing in such a way that it broadly surveys the layout of vmas and pages and be conscious of whether pages spanned vmas or multiple vmas were representing maps of of fragments of pages, so I'm not convinced there's anything particularly unique to be afraid of here.

Just to be clear: I don't want this.

Quoted 91 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.

Potential benefits of the approach (assuming 64k pages):

- The order-0 page size cuts struct page overhead by a factor of 16. From

     ~1.6% of RAM to ~0.1%;

- TLB wins on machines with TLB coalescing as long as mapping is naturally

     aligned;

- Order-5 allocation is 2M, resulting in less pressure on the zone lock;

- 1G pages are within possibility for the buddy allocator - order-14 allocation. It can open the road to 1G THPs.

- As with THP, fewer pages - less pressure on the LRU lock;

- ...

The trade-off is memory waste (similar to what we have on architectures with native 64k pages today) and complexity, mostly in the core-MM code.

== Design considerations ==

I want to split PAGE_SIZE into two distinct values:

- PTE_SIZE defines the virtual address space granularity;

- PG_SIZE defines the size of the order-0 buddy allocation;

PAGE_SIZE is only defined if PTE_SIZE == PG_SIZE. It will flag which code requires conversion, and keep existing code working while conversion is in progress.

The same split happens for other page-related macros: mask, shift, alignment helpers, etc.

PFNs are in PTE_SIZE units.

The buddy allocator and page cache (as well as all I/O) operate in PG_SIZE units.

Userspace mappings are maintained with PTE_SIZE granularity. No ABI changes for userspace. But we might want to communicate PG_SIZE to userspace to get the optimal results for userspace that cares.

PTE_SIZE granularity requires a substantial rework of page fault and VMA handling:

- A struct page pointer and pgprot_t are not enough to create a PTE entry. We also need the offset within the page we are creating the PTE for.

- Since the VMA start can be aligned arbitrarily with respect to the underlying page, vma->vm_pgoff has to be changed to vma->vm_pteoff, which is in PTE_SIZE units.

- The page fault handler needs to handle PTE_SIZE < PG_SIZE, including

     misaligned cases;

Page faults into file mappings are relatively simple to handle as we always have the page cache to refer to. So you can map only the part of the page that fits in the page table, similarly to fault-around.

Anonymous and file-CoW faults should also be simple as long as the VMA is aligned to PG_SIZE in both the virtual address space and with respect to vm_pgoff. We might waste some memory on the ends of the VMA, but it is tolerable.

Misaligned anonymous and file-CoW faults are a pain. Specifically, mapping pages across a page table boundary. In the worst case, a page is mapped across a PGD entry boundary and PTEs for the page have to be put in two separate subtrees of page tables.

A naive implementation would map different pages on different sides of a page table boundary and accept the waste of one page per page table crossing. The hope is that misaligned mappings are rare, but this is suboptimal.

Quoted 6 lines

mremap(2) is the ultimate stress test for the design.

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

When discussing per-process page sizes with Ryan and Dev, I mentioned that having a larger emulated page size could be interesting for other architectures as well.

That is, we would emulate a 64K page size on Intel for user space as well, but let the OS work with 4K pages.

We'd only allocate+map large folios into user space + pagecache, but still allow for page tables etc. to not waste memory.

So "most" of your allocations in the system would actually be at least 64k, reducing zone lock contention etc.

It doesn't solve all the problems you wanted to tackle on your list (e.g., "struct page" overhead, which will be sorted out by memdescs).

--
Cheers,

David

Quoted 110 lines · David Hildenbrand (Arm)

Quoted 91 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.

Potential benefits of the approach (assuming 64k pages):

- The order-0 page size cuts struct page overhead by a factor of 16. From

     ~1.6% of RAM to ~0.1%;

- TLB wins on machines with TLB coalescing as long as mapping is naturally

     aligned;

- Order-5 allocation is 2M, resulting in less pressure on the zone lock;

- 1G pages are within possibility for the buddy allocator - order-14 allocation. It can open the road to 1G THPs.

- As with THP, fewer pages - less pressure on the LRU lock;

- ...

The trade-off is memory waste (similar to what we have on architectures with native 64k pages today) and complexity, mostly in the core-MM code.

== Design considerations ==

I want to split PAGE_SIZE into two distinct values:

- PTE_SIZE defines the virtual address space granularity;

- PG_SIZE defines the size of the order-0 buddy allocation;

PAGE_SIZE is only defined if PTE_SIZE == PG_SIZE. It will flag which code requires conversion, and keep existing code working while conversion is in progress.

The same split happens for other page-related macros: mask, shift, alignment helpers, etc.

PFNs are in PTE_SIZE units.

The buddy allocator and page cache (as well as all I/O) operate in PG_SIZE units.

Userspace mappings are maintained with PTE_SIZE granularity. No ABI changes for userspace. But we might want to communicate PG_SIZE to userspace to get the optimal results for userspace that cares.

PTE_SIZE granularity requires a substantial rework of page fault and VMA handling:

- A struct page pointer and pgprot_t are not enough to create a PTE entry. We also need the offset within the page we are creating the PTE for.

- Since the VMA start can be aligned arbitrarily with respect to the underlying page, vma->vm_pgoff has to be changed to vma->vm_pteoff, which is in PTE_SIZE units.

- The page fault handler needs to handle PTE_SIZE < PG_SIZE, including

     misaligned cases;

Page faults into file mappings are relatively simple to handle as we always have the page cache to refer to. So you can map only the part of the page that fits in the page table, similarly to fault-around.

Anonymous and file-CoW faults should also be simple as long as the VMA is aligned to PG_SIZE in both the virtual address space and with respect to vm_pgoff. We might waste some memory on the ends of the VMA, but it is tolerable.

Misaligned anonymous and file-CoW faults are a pain. Specifically, mapping pages across a page table boundary. In the worst case, a page is mapped across a PGD entry boundary and PTEs for the page have to be put in two separate subtrees of page tables.

A naive implementation would map different pages on different sides of a page table boundary and accept the waste of one page per page table crossing. The hope is that misaligned mappings are rare, but this is suboptimal.

Quoted 6 lines

mremap(2) is the ultimate stress test for the design.

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

When discussing per-process page sizes with Ryan and Dev, I mentioned that having a larger emulated page size could be interesting for other architectures as well.

That is, we would emulate a 64K page size on Intel for user space as well, but let the OS work with 4K pages.

We'd only allocate+map large folios into user space + pagecache, but still allow for page tables etc. to not waste memory.

Quoted 6 lines

So "most" of your allocations in the system would actually be at least 64k, reducing zone lock contention etc.

It doesn't solve all the problems you wanted to tackle on your list (e.g., "struct page" overhead, which will be sorted out by memdescs).

Hi Kiryl,

I'd be interested to discuss this at LSFMM.

On Android, we have a separate but related use case: we emulate the userspace page size on x86, primarily to enable app developers to conduct compatibility testing of their apps for 16KB Android devices.
[1]

It mainly works by enforcing a larger granularity on the VMAs to emulate a userspace page size, somewhat similar to what David mentioned, while the underlying kernel still operates on a 4KB granularity. [2]

IIUC the current design would not enfore the larger granularity / alignment for VMAs to avoid breaking ABI. However, I'd be interest to discuss whether it can be extended to cover this usecase as well.

[1] https://developer.android.com/guide/practices/page-sizes#16kb-emulator
[2] https://source.android.com/docs/core/architecture/16kb-page-size/getting-started-cf-x86-64-pgagnostic

Thanks,
Kalesh

Quoted 6 lines

--
Cheers,

David

Quoted 133 lines · Kalesh Singh

Quoted 110 lines · David Hildenbrand (Arm)

Quoted 91 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.

Potential benefits of the approach (assuming 64k pages):

- The order-0 page size cuts struct page overhead by a factor of 16. From

     ~1.6% of RAM to ~0.1%;

- TLB wins on machines with TLB coalescing as long as mapping is naturally

     aligned;

- Order-5 allocation is 2M, resulting in less pressure on the zone lock;

- 1G pages are within possibility for the buddy allocator - order-14 allocation. It can open the road to 1G THPs.

- As with THP, fewer pages - less pressure on the LRU lock;

- ...

The trade-off is memory waste (similar to what we have on architectures with native 64k pages today) and complexity, mostly in the core-MM code.

== Design considerations ==

I want to split PAGE_SIZE into two distinct values:

- PTE_SIZE defines the virtual address space granularity;

- PG_SIZE defines the size of the order-0 buddy allocation;

PAGE_SIZE is only defined if PTE_SIZE == PG_SIZE. It will flag which code requires conversion, and keep existing code working while conversion is in progress.

The same split happens for other page-related macros: mask, shift, alignment helpers, etc.

PFNs are in PTE_SIZE units.

The buddy allocator and page cache (as well as all I/O) operate in PG_SIZE units.

Userspace mappings are maintained with PTE_SIZE granularity. No ABI changes for userspace. But we might want to communicate PG_SIZE to userspace to get the optimal results for userspace that cares.

PTE_SIZE granularity requires a substantial rework of page fault and VMA handling:

- A struct page pointer and pgprot_t are not enough to create a PTE entry. We also need the offset within the page we are creating the PTE for.

- Since the VMA start can be aligned arbitrarily with respect to the underlying page, vma->vm_pgoff has to be changed to vma->vm_pteoff, which is in PTE_SIZE units.

- The page fault handler needs to handle PTE_SIZE < PG_SIZE, including

     misaligned cases;

Page faults into file mappings are relatively simple to handle as we always have the page cache to refer to. So you can map only the part of the page that fits in the page table, similarly to fault-around.

Anonymous and file-CoW faults should also be simple as long as the VMA is aligned to PG_SIZE in both the virtual address space and with respect to vm_pgoff. We might waste some memory on the ends of the VMA, but it is tolerable.

Misaligned anonymous and file-CoW faults are a pain. Specifically, mapping pages across a page table boundary. In the worst case, a page is mapped across a PGD entry boundary and PTEs for the page have to be put in two separate subtrees of page tables.

A naive implementation would map different pages on different sides of a page table boundary and accept the waste of one page per page table crossing. The hope is that misaligned mappings are rare, but this is suboptimal.

Quoted 6 lines

mremap(2) is the ultimate stress test for the design.

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

When discussing per-process page sizes with Ryan and Dev, I mentioned that having a larger emulated page size could be interesting for other architectures as well.

That is, we would emulate a 64K page size on Intel for user space as well, but let the OS work with 4K pages.

We'd only allocate+map large folios into user space + pagecache, but still allow for page tables etc. to not waste memory.

Quoted 6 lines

So "most" of your allocations in the system would actually be at least 64k, reducing zone lock contention etc.

It doesn't solve all the problems you wanted to tackle on your list (e.g., "struct page" overhead, which will be sorted out by memdescs).

Hi Kiryl,

I'd be interested to discuss this at LSFMM.

On Android, we have a separate but related use case: we emulate the userspace page size on x86, primarily to enable app developers to conduct compatibility testing of their apps for 16KB Android devices.
[1]

It mainly works by enforcing a larger granularity on the VMAs to emulate a userspace page size, somewhat similar to what David mentioned, while the underlying kernel still operates on a 4KB granularity. [2]

Quoted 3 lines

IIUC the current design would not enfore the larger granularity / alignment for VMAs to avoid breaking ABI. However, I'd be interest to discuss whether it can be extended to cover this usecase as well.

I don't want to break ABI, but might add a knob (maybe personality(2) ?) for enforcement to see what breaks.

In general, I would prefer to advertise a new value to userspace that would mean preferred virtual address space granularity.

Quoted 17 lines

[1] https://developer.android.com/guide/practices/page-sizes#16kb-emulator
[2] https://source.android.com/docs/core/architecture/16kb-page-size/getting-started-cf-x86-64-pgagnostic

Thanks,
Kalesh

Quoted 6 lines

--
Cheers,

David

--
Kiryl Shutsemau / Kirill A. Shutemov

- The order-0 page size cuts struct page overhead by a factor of 16. From

    ~1.6% of RAM to ~0.1%;

Quoted 2 lines · Kiryl Shutsemau

- The order-0 page size cuts struct page overhead by a factor of 16. From

    ~1.6% of RAM to ~0.1%;

...
But, it will mostly be getting better performance at the _cost_ of consuming more RAM, not saving RAM.

Quoted 6 lines · Dave Hansen

Quoted 2 lines · Kiryl Shutsemau

- The order-0 page size cuts struct page overhead by a factor of 16. From

    ~1.6% of RAM to ~0.1%;

...
But, it will mostly be getting better performance at the _cost_ of consuming more RAM, not saving RAM.

That's fair.

The problem with struct page memory consumption is that it is static and cannot be reclaimed. You pay the struct page tax no matter what.

Page cache rounding overhead can be large, but a motivated userspace can keep it under control by avoiding splitting a dataset into many small files. And this memory is reclaimable.

Quoted 8 lines · Kiryl Shutsemau

Quoted 6 lines · Dave Hansen

Quoted 2 lines · Kiryl Shutsemau

- The order-0 page size cuts struct page overhead by a factor of 16. From

    ~1.6% of RAM to ~0.1%;

...
But, it will mostly be getting better performance at the _cost_ of consuming more RAM, not saving RAM.

Quoted 9 lines

That's fair.

The problem with struct page memory consumption is that it is static and cannot be reclaimed. You pay the struct page tax no matter what.

Page cache rounding overhead can be large, but a motivated userspace can keep it under control by avoiding splitting a dataset into many small files. And this memory is reclaimable.

But we are in reclaim a lot more these days. As I'm sure you are aware, we are trying to maximize the resources (both cpu and ram) of any machine powered on. Entering reclaim will consume the cpu time and will affect other tasks.

Especially with multiple workload machines, the tendency is to have a primary focus with the lower desired work being killed, if necessary. Reducing the overhead just means more secondary tasks, or a bigger footprint of the ones already executing.

Increasing the memory pressure will degrade the primary workload more frequently, even if we recover enough to avoid OOMing the secondary.

While in the struct page tax world, the secondary task would be killed after a shorter (and less frequently executed) reclaim comes up short. So, I would think that we would be degrading the primary workload in an attempt to keep the secondary alive? Maybe I'm over-simplifying here?

Near the other end of the spectrum, we have chromebooks that are constantly in reclaim, even with 4k pages. I guess these machines would be destine to maintain the same page size they use today. That is, this solution for the struct page tax is only useful if you have a lot of memory. But then again, that's where the bookkeeping costs become hard to take.

Quoted 29 lines · Liam R. Howlett

Quoted 8 lines · Kiryl Shutsemau

Quoted 6 lines · Dave Hansen

Quoted 2 lines · Kiryl Shutsemau

- The order-0 page size cuts struct page overhead by a factor of 16. From

    ~1.6% of RAM to ~0.1%;

...
But, it will mostly be getting better performance at the _cost_ of consuming more RAM, not saving RAM.

Quoted 9 lines

That's fair.

The problem with struct page memory consumption is that it is static and cannot be reclaimed. You pay the struct page tax no matter what.

Page cache rounding overhead can be large, but a motivated userspace can keep it under control by avoiding splitting a dataset into many small files. And this memory is reclaimable.

But we are in reclaim a lot more these days. As I'm sure you are aware, we are trying to maximize the resources (both cpu and ram) of any machine powered on. Entering reclaim will consume the cpu time and will affect other tasks.

Especially with multiple workload machines, the tendency is to have a primary focus with the lower desired work being killed, if necessary. Reducing the overhead just means more secondary tasks, or a bigger footprint of the ones already executing.

Quoted 7 lines

Increasing the memory pressure will degrade the primary workload more frequently, even if we recover enough to avoid OOMing the secondary.

While in the struct page tax world, the secondary task would be killed after a shorter (and less frequently executed) reclaim comes up short. So, I would think that we would be degrading the primary workload in an attempt to keep the secondary alive? Maybe I'm over-simplifying here?

I am not sure I fully follow your point.

Sizing tasks and scheduling tasks between machines is hard in general. I don't think the balance between struct page tax and page cache rounding overhead is going to be the primary factor.

Quoted 38 lines · Kiryl Shutsemau

Quoted 29 lines · Liam R. Howlett

Quoted 8 lines · Kiryl Shutsemau

Quoted 6 lines · Dave Hansen

Quoted 2 lines · Kiryl Shutsemau

- The order-0 page size cuts struct page overhead by a factor of 16. From

    ~1.6% of RAM to ~0.1%;

...
But, it will mostly be getting better performance at the _cost_ of consuming more RAM, not saving RAM.

Quoted 9 lines

That's fair.

The problem with struct page memory consumption is that it is static and cannot be reclaimed. You pay the struct page tax no matter what.

Page cache rounding overhead can be large, but a motivated userspace can keep it under control by avoiding splitting a dataset into many small files. And this memory is reclaimable.

But we are in reclaim a lot more these days. As I'm sure you are aware, we are trying to maximize the resources (both cpu and ram) of any machine powered on. Entering reclaim will consume the cpu time and will affect other tasks.

Especially with multiple workload machines, the tendency is to have a primary focus with the lower desired work being killed, if necessary. Reducing the overhead just means more secondary tasks, or a bigger footprint of the ones already executing.

Quoted 7 lines

Increasing the memory pressure will degrade the primary workload more frequently, even if we recover enough to avoid OOMing the secondary.

While in the struct page tax world, the secondary task would be killed after a shorter (and less frequently executed) reclaim comes up short. So, I would think that we would be degrading the primary workload in an attempt to keep the secondary alive? Maybe I'm over-simplifying here?

Quoted 5 lines

I am not sure I fully follow your point.

Sizing tasks and scheduling tasks between machines is hard in general. I don't think the balance between struct page tax and page cache rounding overhead is going to be the primary factor.

I think there are more trade offs than what you listed. It's still probably worth doing, but I wanted to know if you though that this would cause us to spend more time in reclaim, which seems to be implied above. So, another trade-off might be all the reclaim penalty being paid more frequently?

First of all, this looks like fun. Nice work! I'm not opposed at all in concept to cleaning up things and doing the logical separation you described to split buddy granularity and mapping granularity. That seems like a worthy endeavor and some of the union/#define tricks look like a likely viable way to do it incrementally.

But I don't think there's going to be a lot of memory savings in the end. Maybe this would bring the mem= hyperscalers back into the fold and have them actually start using 'struct page' again for their VM memory. Dunno.

But, let's look at my kernel directory and round the file sizes up to 4k, 16k and 64k:

find .  -printf '%s\n' | while read size; do echo	\
		$(((size + 0x0fff) & 0xfffff000))	\
		$(((size + 0x3fff) & 0xffffc000))	\
		$(((size + 0xffff) & 0xffff0000));

done
... and add them all up:
11,297,648 KB - on disk
11,297,712 KB - in a 4k page cache
12,223,488 KB - in a 16k page cache
16,623,296 KB - in a 64k page cache

So a 64k page cache eats ~5GB of extra memory for a kernel tree (well, _my_ kernel tree). In other words, if you are looking for memory savings on my laptop, you'll need ~300GB of RAM before 'struct page' overhead overwhelms the page cache bloat from a single kernel tree.

The whole kernel obviously isn't in the page cache all at the same time. The page cache across the system is also obviously different than a kernel tree, but you get the point.
That's not to diminish how useful something like this might be, especially for folks that are sensitive to 'struct page' overhead or allocator performance.
But, it will mostly be getting better performance at the _cost_ of consuming more RAM, not saving RAM.

Quoted 4 lines · Dave Hansen

So a 64k page cache eats ~5GB of extra memory for a kernel tree (well, _my_ kernel tree). In other words, if you are looking for memory savings on my laptop, you'll need ~300GB of RAM before 'struct page' overhead overwhelms the page cache bloat from a single kernel tree.

Quoted 8 lines

The whole kernel obviously isn't in the page cache all at the same time. The page cache across the system is also obviously different than a kernel tree, but you get the point.
That's not to diminish how useful something like this might be, especially for folks that are sensitive to 'struct page' overhead or allocator performance.
But, it will mostly be getting better performance at the _cost_ of consuming more RAM, not saving RAM.

Given that you don't remember the project at all, I can assume the IBM-internal whitepaper where I described doing tail packing for small files in the pagecache as part of an array of strategies to mitigate internal fragmentation and latency issues expected to arise for large values of PAGE_MMUSHIFT is also forgotten. I wrote some things I thought worthwhile there and I was hoping you'd be able to at least corroborate the one-time, now-former existence of the thing and maybe some smatterings of its contents since it's no longer extant.

 I dont think this discussion could make forward progress without clearly drawing the rule of thumb that which page size is supposed to match what RAM size, with the supported page size put aside now, because I dont know why 128K page is needed in the xbc/yz environment.

     RAM size    page size
     32G        4K
     512G        128K
     4T        2M

The patchset is large:

 378 files changed, 3348 insertions(+), 3102 deletions(-)

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

On 2/19/26 07:08, Kiryl Shutsemau wrote:
...

Quoted 3 lines

The patchset is large:

 378 files changed, 3348 insertions(+), 3102 deletions(-)

A few notes about the diffstats:

$ git diff v6.17..HEAD arch/x86 | diffstat | tail -1
 105 files changed, 874 insertions(+), 843 deletions(-)
$ git diff v6.17..HEAD mm | diffstat | tail -1
 53 files changed, 1136 insertions(+), 1069 deletions(-)

The vast, vast majority of this seems to be the renames. Stuff like:

Review

Quoted 2 lines

(quoted diff) +1 -1

-               new = round_down(new, PAGE_SIZE);
+               new = round_down(new, PTE_SIZE);

or even less worrying:

Review

Quoted 2 lines

(quoted diff) +1 -1

-int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid);
+int set_direct_map_valid_noflush(struct page *page, unsigned numpages, bool valid);

That stuff obviously needs to be audited but it's far less concerning than the logic changes.

So just for review sanity, if you go forward with this, I'd very much appreciate a strong separation of the purely mechanical bits from any logic changes.

Quoted 4 lines

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

Others mentioned this, but I think this essentially gates what you are doing behind a full tree conversion over to ptdescs.

The most useful thing we can do with this series is look at it and decide what _other_ things need to get done before the tree could possibly go in that direction, like ptdesc or a the disambiguation between PTE_SIZE and PG_SIZE that you've kicked off here.

Quoted 2 lines

Others mentioned this, but I think this essentially gates what you are doing behind a full tree conversion over to ptdescs.

I have not followed ptdescs closely. Need to catch up.

For PoC, I will just waste full order-0 page for page table. Packing is not required for correctness.

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

Quoted 4 lines · Kiryl Shutsemau

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

Have you looked at the s390/ppc implementations (yes, they're different, no, that sucks)?

slab seems like the wrong approach to me.

There's a third approach that I've never looked at which is to allocate the larger size, then just use it for N consecutive entries.

Quoted 4 lines

On x86, page tables are allocated from the buddy allocator and if PG_SIZE is greater than 4 KB, we need a way to pack multiple page tables into a single page. We could use the slab allocator for this, but it would require relocating the page-table metadata out of struct page.

Have you looked at the s390/ppc implementations (yes, they're different, no, that sucks)? slab seems like the wrong approach to me.

There's a third approach that I've never looked at which is to allocate the larger size, then just use it for N consecutive entries.

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

Quoted 3 lines · On Thu, 19 Feb 2026 15:08:51 +0000 Kiryl Shutsemau <[email protected]> wrote:

No, there's no new hardware (that I know of). I want to explore what page size means.

Quoted 5 lines

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

Also the 'random' buffers that are PAGE_SIZE rather than 4k.

I also wonder how is affects mmap of kernel memory and the alignement of PCIe windows (etc).

Quoted 5 lines

No, there's no new hardware (that I know of). I want to explore what page size means.
The kernel uses the same value - PAGE_SIZE - for two things:
- the order-0 buddy allocation size;
- the granularity of virtual address space mapping;

Also the 'random' buffers that are PAGE_SIZE rather than 4k. I also wonder how is affects mmap of kernel memory and the alignement of PCIe windows (etc).

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

Quoted 7 lines · Kiryl Shutsemau

No, there's no new hardware (that I know of). I want to explore what page size means.

The kernel uses the same value - PAGE_SIZE - for two things:

- the order-0 buddy allocation size;

Quoted 5 lines

- the granularity of virtual address space mapping;

I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.

I actually want to go in the other direction. I once came up with a name -- POTAM -- which stands for Power Of Two Allocator with Metadata.

The use case was something like XFS's buffer cache where we want a filesystem block size of data (so 0.5KiB to 64KiB) with some metadata attached (xfs_buf is 664 bytes with debugging enabled!)

I set this aside to work on folios, but folios offer a back door to unifying this with the buddy allocator. It's a long road, but here's a sketch:

First, we separate memdescs from pages. I believe this lets us shrink struct page down to 8 bytes (previously presented as various LSFMMs).

Second, we get rid of 'page' in things like sglist and bvec. This is already in progress for various other good reasons.

Third (this bit is new), we replace memmap with something like a maple tree. That lets us lookup memdescs by physical address (typically a memdesc will contain either the physical or virtual address of the memory it controls).

Fourth, we change the unit of the lookup in the maple tree from being a PFN to being address / 512 (or whatever size we want to use as our minimum).

Now we can have memdescs for an arbitrary power of two which means we can ditch all the awful code from ppc/s390 page table handling where they try to share one memdesc between several different page tables.

It's going to be "fun" avoiding allocation deadlocks where we want to rebalance the maple tree containing the memdescs ... that's a five year away problem.

Fourth, we change the unit of the lookup in the maple tree from being a PFN to being address / 512 (or whatever size we want to use as our minimum).

Now we can have memdescs for an arbitrary power of two which means we can ditch all the awful code from ppc/s390 page table handling where they try to share one memdesc between several different page tables.

== Status ==

I have a POC implementation on top of v6.17:

git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git pte_size

Quoted 5 lines · Kiryl Shutsemau

== Status ==

I have a POC implementation on top of v6.17:

git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git pte_size

Just a heads up.

I've updated the tree. It is on top of v7.0 now.

I can boot my VM fully (not only to shell as before) on all three page size 4k, 16k and 64k. And it doesn't crash immediately.

Page fault handler is the most challenging part of the design. I wanted to flash it out to RFC quality before the summit, but it is not there yet. But it started getting a shape.

Volume of the code changes makes it hard to deal with the patchset:

 1530 files changed, 12675 insertions(+), 8669 deletions(-)

Quoted 18 lines · Kiryl Shutsemau

Quoted 5 lines · Kiryl Shutsemau

== Status ==

I have a POC implementation on top of v6.17:

git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git pte_size

Just a heads up.

I've updated the tree. It is on top of v7.0 now.

I can boot my VM fully (not only to shell as before) on all three page size 4k, 16k and 64k. And it doesn't crash immediately.

Page fault handler is the most challenging part of the design. I wanted to flash it out to RFC quality before the summit, but it is not there yet. But it started getting a shape.

Quoted 3 lines

Volume of the code changes makes it hard to deal with the patchset:

 1530 files changed, 12675 insertions(+), 8669 deletions(-)

I think you know the answer already :P

Quoted 15 lines · David Hildenbrand (Arm)

Quoted 14 lines · Kiryl Shutsemau

Just a heads up.

I've updated the tree. It is on top of v7.0 now.

I can boot my VM fully (not only to shell as before) on all three page size 4k, 16k and 64k. And it doesn't crash immediately.

Page fault handler is the most challenging part of the design. I wanted to flash it out to RFC quality before the summit, but it is not there yet. But it started getting a shape.

Volume of the code changes makes it hard to deal with the patchset:

Quoted 3 lines

Quoted 1 line

 1530 files changed, 12675 insertions(+), 8669 deletions(-)

I think you know the answer already :P

:/

Let me present the case at least.

Quoted 5 lines · Kiryl Shutsemau

== Status ==

I have a POC implementation on top of v6.17:

git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git pte_size

Just a heads up.

I've updated the tree. It is on top of v7.0 now.

I can boot my VM fully (not only to shell as before) on all three page size 4k, 16k and 64k. And it doesn't crash immediately.

Page fault handler is the most challenging part of the design. I wanted to flash it out to RFC quality before the summit, but it is not there yet. But it started getting a shape.

Volume of the code changes makes it hard to deal with the patchset:

 1530 files changed, 12675 insertions(+), 8669 deletions(-)

Most of it mechanical, but still.

--
Kiryl Shutsemau / Kirill A. Shutemov

No, there's no new hardware (that I know of). I want to explore what page size means.
The kernel uses the same value - PAGE_SIZE - for two things:
- the order-0 buddy allocation size;
- the granularity of virtual address space mapping;
I think we can benefit from separating these two meanings and allowing order-0 allocations to be larger than the virtual address space covered by a PTE entry.
The main motivation is scalability. Managing memory on multi-terabyte machines in 4k is suboptimal, to say the least.