LWN: Comments on "Allocator optimizations for transparent huge pages"

Allocator optimizations for transparent huge pages

yuzhao@google.com — Mon, 03 Jun 2024 05:14:29 +0000

Slides attached here: https://lore.kernel.org/CAOUHufY_2e3gWF1uJD8-OG+1cQd3Dfry...

Allocator optimizations for transparent huge pages

willy — Thu, 30 May 2024 01:51:22 +0000

We don't support migrating the memory which underlies a vmalloc allocation, for exactly this reason.

Allocator optimizations for transparent huge pages

page_walker — Wed, 29 May 2024 14:17:07 +0000

We can try to vmalloc everything in kernel and not use direct mapping at all. That means a kernel data access can trigger a page fault, when the page is under migration. That could cause recursive page faults, if kernel is handling a user page fault or a kernel page fault.

Allocator optimizations for transparent huge pages

david.hildenbrand — Tue, 28 May 2024 11:10:00 +0000

Page tables used for user space process are very dynamic and are the problematic bit. Page tables used for the direct map are (besides memory hot(un)plug) static and we try to make use of huge mappings if possible.

Allocator optimizations for transparent huge pages

taladar — Tue, 28 May 2024 07:31:51 +0000

Assuming no memory hot swapping, aren't page tables basically a fixed size for the entire lifetime of a system (as in between two reboots)? Wouldn't they be ideally allocated as huge pages themselves?

Allocator optimizations for transparent huge pages

david.hildenbrand — Mon, 27 May 2024 19:32:27 +0000

I looked at this once (migration of leaf page tables only) and it turned into complexity. It can be done I think, given sufficient brain power and time.

But it‘s only the tip of the iceberg I’m afraid. Many/most allocations in the kernel are unmovable, only selected (pagecache, anonymous memory, zsmallloc) are movable. We see a lot more unmovable allocations lately, the trend is going into the wrong direction: secretmem and guest_memfd don‘t support page migration at all.

Allocator optimizations for transparent huge pages

DemiMarie — Mon, 27 May 2024 16:18:41 +0000

Could page tables be made movable?

Allocator optimizations for transparent huge pages

david.hildenbrand — Mon, 27 May 2024 10:04:55 +0000

Especially page tables (and many more things) are unmovable and 4k. Instead of refusing to allocate them, we should do a better job at grouping them to restrict fragmentation locally (what pageblocks already do, and there is work in progress to improve the situation).

Allocator optimizations for transparent huge pages

DemiMarie — Sun, 26 May 2024 04:18:04 +0000

Could the kernel refuse to allocate 4k pages that are not movable? Then any fragmentation they cause can be corrected via compaction.