Memory Folios Updated A 14th Time For Improving Linux Memory Management

[coder]

I can't speak for all the (apparently pretty poor) "defensive" code in there, but you you only need a handful of places that assume pages are 4K (or any other specific size) to run into all kinds of weird/broken/whatever behavior, all of which will always be blamed on the patchset rather than the defective code. Tracking that sort of thing down is a lot more work than writing a new allocator is.

This isn't about page size. The kernel already supported variable sizes for a long, long time.

This seems to be about APIs which operate at a higher level of abstraction than individual pages. However, the kernel lacked datatypes to express that. So, that's why they had to bend over backwards to do everything in terms of pages.

The normal thing to do is introduce the new datatype and gradually start transitioning code over to it. However, I can understand that the kernel folks probably prefer to have everything transitioned over in one go. That does set a high bar, and maybe that's the reason this didn't happen sooner.

[coder]

That said, just checked my own (proprietary) tree, and a lot of stuff hangs on having 4096 byte pages.

Oh, well, guess I'll call it job security

Um, perhaps you weren't aware that even x86 supports other page sizes, such as 2 MB? I think that's not uncommon in some cloud environments.

https://en.wikipedia.org/wiki/Page_(computer_memory)#Multiple_page_sizes

[gilboa]

Um, perhaps you weren't aware that even x86 supports other page sizes, such as 2 MB? I think that's not uncommon in some cloud environments.

https://en.wikipedia.org/wiki/Page_(...ple_page_sizes

I was aware. Never needed to support it given the fact the our proprietary software runs only in controlled environments that rarely used huge pages. (In short, alloc_pages_node and PAGE_SIZE simply works )

- Gilboa