lkml.org 
[lkml]   [2023]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RESEND PATCH v7 00/10] Small-sized THP for anonymous memory
From
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@redhat.com/
>
> And yet:
> https://lore.kernel.org/linux-mm/20231106193315.GB3661273@cmpxchg.org/
>
> "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

\
 
 \ /
  Last update: 2023-11-23 17:51    [W:0.101 / U:1.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site