@jann Hm I own an AMD machine, maybe I should experiment with it...

@jann

>By the time khugepaged comes around, fault scalability is probably not much of a concern anymore, right? Since you're probably done faulting when khugepaged comes around to collapse stuff? Unless we're talking about swapin performance. But yeah, reclaim I could see.

ok yeah from khugepaged point of view right. Sorry getting ahead of things there come in handy at _the point of page fault_ when/if we implement mTHP there.

>I think you wouldn't get a benefit out of it in terms of TLB - like, on modern AMD machines, I believe if you can't get a 16K page, then the TLB will have to use 4K entries anyway and from the TLB perspective, there's no sense in having 8K pages?

You can have a while range of mTHP size 1mb, 512 kb, 256 kb, 128 kb, 64 kb, 32 kb, 16 kb I believe on arm for instance.

I think for AMD the benefits are a lot less clear.

Honestly I see this largely right now as an arm64 feature.

@jann TLB is an obvious improvement, but establishing higher order folios will have fault scalability/reclaim advantages also.

I don't know whether the latter has as much impact of the former.

As for follow up, I think you could at least in theory benefit from multiple mTHP sizes as if we were unable to obtain a larger mTHP size we could try for smaller, but you'd always want to have the largest possible.

Note that this (painfully) also aligns with with the max_pte_none logic which determines how much memory you want to 'waste' on collapse should you find adjacent unmapped ranges.

We are working on a saner means of doing this. See https://lore.kernel.org/linux-mm/dcfc7e27-d3c8-4fd0-8b7b-ce8f5051d597@lucifer.local/T/#m2ecc263112f715710cd6745a6a7ed211aeed92fe and above for much discussion on this.

@jann why not both?