Re: [RFC PATCH 0/4] Multiple consecutive page for anonymous mapping

[David Hildenbrand <david@redhat.com>]

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