Re: ANON_LARGE_FOLIOS meeting follow-up & refined proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!

> 
> 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 ;-)

> 
> 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
I would like to move focus to other changes that build on this, and that's
difficult while this is still not merged.

> 





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux