@ljs btw, one more comment about mTHP: I know Android has been making a push for supporting 16K native page size on arm64 for performance reasons since years ago, I kinda wonder how much of that is being obsoleted by mTHP

@jann @ljs Intuitively I doubt much. I wish it was possible to manage memory (and disk space) in tiny chunks without performance overhead, but sadly we don’t live in that world.

@jann @ljs I do wish that all pages not pinned for I/O were transparently movable, with page faults acting as read and write barriers to allow concurrent compaction.

@alwayscurious @ljs I mean, that is basically the case for anonymous and page cache memory, that's what compaction is... and pageblocks should prevent other, non-movable allocations from landing in between movable allocations

@alwayscurious @ljs or are you saying there is some specific performance property you want where you'd want to avoid having a thread wait in a page fault handler until some TLB flushes and a couple-kilobytes memcpy are done? is that really an issue?

@alwayscurious @ljs I think the point of mTHP is that even in a system that is capable of managing memory in tiny chunks, you can still manage some of the memory in bigger chunks and get many of the same performance benefits as you'd get from cranking up the system-wide page size? Even TLBs have that baked in as a feature nowadays.

Apart from the memory used to store struct page and page tables, I don't think Linux has all that many corners where you have to pay the cost of managing stuff at a 4K level when you're logically managing stuff in bigger chunks.

@jann @ljs I want the majority of kernel memory to be movable, like it is on Windows.

@alwayscurious @ljs
a) why, do you see a large chunk of RAM being used for stuff other than anon/file pages, or are page blocks not working as intended?
b) if SLUB_VIRTUAL works out then maybe that will eventually become a little bit more possible with lots of asterisks

@jann well,the 'glorious folio future' is ideally indeed that a larger base size should not be necessary.

I think _right now_ while mTHP is still a little dumb and the folio project continues the asnwer is no, but in future one hopes the answer is yes :)

@jann @alwayscurious movable kernel memory would be great, it's something we want and I expect @hyeyoo is going to at some point work on :)

VMAs not being unmovable, unreclaimable + uncompactable sucks big time, among other kernel metadata.

@ljs @jann @alwayscurious @vbabka That's one of my projects for next year, planning to start by writing an RFC around the end of this year :)

@hyeyoo @alwayscurious @jann @vbabka good lad