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
