From: Kiryl Shutsemau <kas@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Mike Rapoport <rppt@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Usama Arif <usama.arif@linux.dev>
Subject: Re: [LSF/MM/BPF TOPIC] 64k (or 16k) base page size on x86
Date: Thu, 19 Feb 2026 22:26:22 +0000 [thread overview]
Message-ID: <aZeL8fHz_1WAX49n@thinkstation> (raw)
In-Reply-To: <aZdMqub5RsukLvnv@casper.infradead.org>
On Thu, Feb 19, 2026 at 05:47:22PM +0000, Matthew Wilcox wrote:
> On Thu, Feb 19, 2026 at 03:08:51PM +0000, Kiryl Shutsemau wrote:
> > 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)?
No, will check it out tomorrow.
> slab seems like the wrong approach to me.
I was the first thing that came to mind. I have not put much time into
it
> 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.
Yeah, that's a possible way. We would need to populate 16 page table
entries of the parent page table. But you don't need to care about
fragmentation within the page.
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-02-19 22:26 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 15:08 [LSF/MM/BPF TOPIC] 64k (or 16k) base page size on x86 Kiryl Shutsemau
2026-02-19 15:17 ` Peter Zijlstra
2026-02-19 15:20 ` Peter Zijlstra
2026-02-19 15:27 ` Kiryl Shutsemau
2026-02-19 15:33 ` Pedro Falcato
2026-02-19 15:50 ` Kiryl Shutsemau
2026-02-19 15:53 ` David Hildenbrand (Arm)
2026-02-19 19:31 ` Pedro Falcato
2026-02-19 15:39 ` David Hildenbrand (Arm)
2026-02-19 15:54 ` Kiryl Shutsemau
2026-02-19 16:09 ` David Hildenbrand (Arm)
2026-02-20 2:55 ` Zi Yan
2026-02-19 17:09 ` Kiryl Shutsemau
2026-02-20 10:24 ` David Hildenbrand (Arm)
2026-02-20 12:07 ` Kiryl Shutsemau
2026-02-20 16:30 ` David Hildenbrand (Arm)
2026-02-20 19:33 ` Kalesh Singh
2026-02-23 11:04 ` David Hildenbrand (Arm)
2026-02-23 11:13 ` Kiryl Shutsemau
2026-02-23 11:27 ` David Hildenbrand (Arm)
2026-02-23 12:16 ` Kiryl Shutsemau
2026-02-23 15:14 ` Dave Hansen
2026-02-23 15:31 ` David Hildenbrand (Arm)
2026-02-23 15:45 ` Kiryl Shutsemau
2026-02-23 15:49 ` David Hildenbrand (Arm)
2026-02-23 16:22 ` Lorenzo Stoakes
2026-02-23 16:34 ` David Laight
2026-02-19 23:24 ` Kalesh Singh
2026-02-20 12:10 ` Kiryl Shutsemau
2026-02-20 19:21 ` Kalesh Singh
2026-02-19 17:08 ` Dave Hansen
2026-02-19 22:05 ` Kiryl Shutsemau
2026-02-20 3:28 ` Liam R. Howlett
2026-02-20 12:33 ` Kiryl Shutsemau
2026-02-20 15:17 ` Liam R. Howlett
2026-02-20 15:50 ` Kiryl Shutsemau
2026-02-19 17:30 ` Dave Hansen
2026-02-19 22:14 ` Kiryl Shutsemau
2026-02-19 22:21 ` Dave Hansen
2026-02-19 17:47 ` Matthew Wilcox
2026-02-19 22:26 ` Kiryl Shutsemau [this message]
2026-02-20 9:04 ` David Laight
2026-02-20 12:12 ` Kiryl Shutsemau
2026-04-29 14:39 ` Matthew Wilcox
2026-04-29 15:26 ` Kiryl Shutsemau
2026-05-01 18:05 ` David Hildenbrand (Arm)
2026-05-01 18:00 ` Kiryl Shutsemau
2026-05-01 18:02 ` David Hildenbrand (Arm)
2026-05-01 18:12 ` Kiryl Shutsemau
2026-05-01 18:31 ` David Hildenbrand (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aZeL8fHz_1WAX49n@thinkstation \
--to=kas@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mingo@redhat.com \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--cc=usama.arif@linux.dev \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.