On Mon, Jan 09, 2023 at 06:33:09PM +0100, David Hildenbrand wrote: > (2) This steals consecutive pages to immediately split them up > > I know, everybody thinks it might be valuable for their use case to grab all > higher-order pages :) It will be "fun" once all these cases start competing. > TBH, splitting up them immediately again smells like being the lowest > priority among all higher-order users. Actually, it is good for everybody to allocate higher-order pages, if they can make use of them. It has the end effect of reducing fragmentation (imagine if the base unit of allocation were 512 bytes; every page fault would have to do an order-3 allocation, and it wouldn't be long until order-0 allocations had fragmented memory such that we could no longer service a page fault). Splitting them again is clearly one of the bad things done in this proof-of-concept. Anything that goes upstream won't do that, but I suspect it was necessary to avoid fixing all the places in the kernel that assume anon memory is either order-0 or -9. > (3) All effort will be lost once page compaction gets active, compacts, > and simply migrates to random 4k pages. This is most probably the > biggest "issue" of the whole approach AFAIKS: it's only temporary > because there is no notion of these pages belonging together > anymore. Sure, page compaction / migration is going to have to learn how to handle order 1-8 folios. Again, not needed for the PoC.
