On 09.01.23 20:11, Matthew Wilcox wrote:
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).
I don't believe that this reasoning is universally true. But I can see
some part being true if everybody would be allocating higher-order pages
and there would be no memory pressure.
Simple example why I am skeptical: Our free lists hold a order-9 page
and 4 order-0 pages.
It's counter-intuitive to split (fragment!) the order-9 page to allocate
an order-2 page instead of just "consuming the leftover" and letting
somebody else make use of the full order-9 page (e.g., a proper THP).
Now, reality will tell us if we're handing out
higher-order-but-not-thp-order pages too easily to end up fragmenting
the wrong orders. IMHO,
fragmentation is and remains a challenge ... and I don't think
especially once we have more consumers of higher-order pages --
especially where they might not be that beneficial.
I'm happy to be wrong on this one.
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.
Agreed. An usptream version shouldn't perform this split -- which will
require more work.
--
Thanks,
David / dhildenb
