Re: [LSF/MM/BPF TOPIC] 64k (or 16k) base page size on x86

[Dave Hansen <dave.hansen@intel.com>]

On 2/19/26 07:08, Kiryl Shutsemau wrote:
...
> 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:

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

or even less worrying:

> -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.

> 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.