Re: ANON_LARGE_FOLIOS meeting follow-up & refined proposal

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

 



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





[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