Re: ANON_LARGE_FOLIOS meeting follow-up & refined proposal

[David Hildenbrand <david@redhat.com>]

On 05.10.23 11:46, Ryan Roberts wrote:
> On 05/10/2023 09:15, David Hildenbrand wrote:
>> On 05.10.23 09:37, Ryan Roberts wrote:
>>> On 02/10/2023 13:58, David Hildenbrand wrote:
>>>>> [...]
>>>>>
>>>>> My concern is that the "fresh start" is not as simple as it appears. I've come
>>>>> to the conclusion that if we have a new interface, then it should really be a
>>>>> strict superset of THP to make it extensible in future. But that opens
>>>>> questions
>>>>
>>>> ^ +1
>>>>
>>>>> about how you configure PMD-sized allocations when both interfaces disagree.
>>>>> For
>>>>> "enabled" its fairly straightforward; you can do a logical OR. But its less
>>>>> clear how to handle disagreement over defrag. And then you have huge_zero_page
>>>>> and khugepaged etc, which might just stay with THP. But eventually we will
>>>>
>>>> Probably we want everything that THP had (khugepaged, zeropage, ...) also on
>>>> some (selected?) smaller orders.
>>>>
>>>>> probably want to do async collapse for smaller order folios too, and at that
>>>>> point you have to duplicate all those controls... So I concluded that actually
>>>>> it is cleaner to just bolt on a small-order extension to THP. I've updated all
>>>>> the docs, and that was pretty simple to do, which usually suggests that the
>>>>> extension is purely additive and shouldn't be confusing.
>>>>
>>>> Fine with me. I don't quite like bitmaps exposed to user space, though. Just
>>>> having a user-readable list or a "directory" with various options as files might
>>>> be cleaner ...
>>>>
>>>>>
>>>>> Take a look at the patches, then make a judgement ;-)
>>>>>
>>>>
>>>> ... but we'll discuss it there :)
>>>>
>>>
>>> David, FYI, the patches are posted at [1] (you're cc'ed) and have been in
>>> mm-unstable for nearly a week - so I guess they will go to mm-stable soon by
>>> default. So if you want to object to any of it, now's the time ;-).
>>
>> I just did :P
>>
>> Note that I'm distracted by a tiny human being. I should be back at work tomorrow.
> 
> Ahh - congratulations!

Thanks man!

> 
>>
>> Hopefully other people that participated in the discussions can review and ack
>> in the meantime.
> 
> That would certainly be nice (hint to everyone else on the thread ;-)

Indeed, I'll do my best to provide feedback soon, but I shouldn't be the 
only one doing so :)

[my backlog is crazy large after some sick days, public holidays and 
tiny human beings]

> 
>>
>> IMHO there really is no need to rush at this point.
> 
> I have a couple of selfish reasons; I was hoping to get it into v6.7 since I was
> thinking that would be the next LTS, but I've just done the maths again, and it
> looks like it will be v6.6, so I guess I've missed it anyway. The other is that

Yes, that ship has sailed; also, it's not that much of value if merged 
but cannot be reasonably enabled yet due to other TODOs (IOW, no 
distribution would enable it).

> I would like to move focus to other changes that build on this, and that's
> difficult while this is still not merged.

IMHO, this is one of the big important features comparable to ordinary 
THP back then. We better take our time to get it right (well, rather as 
little wrong as possible :) ).

You can start sending out other work that depends on this, even if not 
merged yet. ... there tends to be a review bottleneck, so don't expect 
fast feedback; but it might be reasonable to let people know what's 
coming up next.

-- 
Cheers,

David / dhildenb