LWN: Comments on "Reducing page structures for huge pages"

Reducing page structures for huge pages

geert — Mon, 14 Dec 2020 12:39:49 +0000

There are actually two structures describing memory:
1. The hardware page tables, used by the MMU, which already have a hierarchical structure using multiple levels,
2. The kernel's own bookkeeping, using struct page, which is what this article is discussing.

Reducing page structures for huge pages

farnz — Sun, 13 Dec 2020 16:07:48 +0000

That's how large pages work on x86 today. The smallest level is 4 KiB pages; 512 of these are mapped by the next level up, which can also be used to map a single 2 MiB huge page. 512 of those are mapped by the next level up, which can also be used to map a single 1 GiB huge page. In theory, Intel/AMD could expand this to let you use a single entry to map 512 GiB contiguous RAM, but that's not interested them yet.

Reducing page structures for huge pages

Wol — Sun, 13 Dec 2020 15:57:47 +0000

I'm probably talking from a position of complete ignorance, but it just struck me - doesn't the page table have several levels?

Would it be possible to make the number of levels variable, such that your normal pages were in level 5 like now, but you could allocate a large page at level 4, or a huge page at level 3, something like that?

And of course, that means you simply break a level 4 page into level 5 pages if you need them, etc etc ...

Cheers,
Wol

Reducing page structures for huge pages

pixelpapst — Sun, 13 Dec 2020 08:15:54 +0000

Does the memory for the "struct page"-filled pages have any specific constraints that make its allocation difficult, beyond needing to sit on the correct NUMA node?

If it doesn't, it seems trivial to allocate these structure pages directly from the set of "returned" pages whenever a huge page is returned. If I'm not missing anything (which I may well be), this should obviate the need for a delayed allocation in this scenario.