Re: [RESEND PATCH v7 00/10] Small-sized THP for anonymous memory

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

 



On 23.11.23 17:18, Matthew Wilcox wrote:
On Thu, Nov 23, 2023 at 05:05:37PM +0100, David Hildenbrand wrote:
On 23.11.23 16:59, Matthew Wilcox wrote:
On Wed, Nov 22, 2023 at 04:29:40PM +0000, Ryan Roberts wrote:
Note: I'm resending this at Andrew's suggestion due to having originally sent
it during LPC. I'm hoping its in a position where the feedback is minor enough
that I can rework in time for v6.8, but so far haven't had any.

Hi All,

This is v7 of a series to implement small-sized THP for anonymous memory
(previously called "large anonymous folios"). The objective of this is to

I'm still against small-sized THP.  We've now got people asking whether
the THP counters should be updated when dealing with large folios that
are smaller than PMD sized.  It's sowing confusion, and we should go
back to large anon folios as a name.


I disagree.

https://lore.kernel.org/all/65dbdf2a-9281-a3c3-b7e3-a79c5b60b357@xxxxxxxxxx/

And yet:
https://lore.kernel.org/linux-mm/20231106193315.GB3661273@xxxxxxxxxxx/

"This is a small THP so we don't account it as a THP, we only account
normal THPs as THPs" is a bizarre position to take.

Not to mention that saying a foo is a small huge baz is just bizarre.
Am I a small giant?  Or just a large human?

I like that analogy. Yet, "small giant" sounds "bigger" in some way IMHO ;)

I'll note that "small-sized THP" is just a temporary feature name, it won't be exposed as such to the user in sysfs etc. In a couple of years, it will be forgotten.

To me it makes sense: it's a hugepage (not a page) but smaller compared to what we previously had. But again, there won't be a "small_thp" toggle anywhere.

Long-term it's simply going to be a THP. Quoting from my writeup:

"Nowadays, when somebody says that they are using hugetlb huge pages, the first question frequently is "which huge page size?". The same will
happen with transparent huge pages I believe.".


Regarding the accounting: as I said a couple of times, "AnonHugePages" should have been called "AnonPmdMapped" or similar; that's what it really is: as soon as a THP is PTE-mapped, it's not accounted there. But we can't fix that I guess, unless we add some "world switch" for any workloads that would care about a different accounting.

So we're really only concerned about:
* AnonHugePages
* ShmemHugePages
* FileHugePages

The question is if we really want to continue extending/adjusting the old meminfo interfaces and talk about how to perform accounting there.

Because, as we learned, we might get a new file-based sysfs based interface, because Greg seems to be against exposing new values in the old single-file-based one.

In a new one, we have all freedom to expose what we actually want nowadays, and can just document that the old interface was designed with the assumption that there is only a single THP size.

... like hugetlb, where we also only expose the "default hugetlb size" parameters for legacy reasons:

HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

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