[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a86351ce-60f8-4390-ad97-5d91ca2bc9dd@redhat.com>
Date: Tue, 28 Nov 2023 09:47:02 +0100
From: David Hildenbrand <david@...hat.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Ryan Roberts <ryan.roberts@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Yin Fengwei <fengwei.yin@...el.com>,
Yu Zhao <yuzhao@...gle.com>,
Catalin Marinas <catalin.marinas@....com>,
Anshuman Khandual <anshuman.khandual@....com>,
Yang Shi <shy828301@...il.com>,
"Huang, Ying" <ying.huang@...el.com>, Zi Yan <ziy@...dia.com>,
Luis Chamberlain <mcgrof@...nel.org>,
Itaru Kitayama <itaru.kitayama@...il.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
John Hubbard <jhubbard@...dia.com>,
David Rientjes <rientjes@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>,
Hugh Dickins <hughd@...gle.com>,
Kefeng Wang <wangkefeng.wang@...wei.com>, linux-mm@...ck.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH v7 00/10] Small-sized THP for anonymous memory
On 28.11.23 05:05, Matthew Wilcox wrote:
> On Fri, Nov 24, 2023 at 06:34:10PM +0100, David Hildenbrand wrote:
>> On 24.11.23 16:53, Matthew Wilcox wrote:
>>>> * we already have PMD-sized "large anon folios" in THP
>>>
>>> Right, those are already accounted as THP, and that's what users expect.
>>> If we're allocating 1024 x 64kB chunks of memory, the user won't be able
>>> to distinguish that from 32 x 2MB chunks of memory, and yet the
>>> performance profile for some applications will be very different.
>>
>> Very right, and because there will be a difference between 1024 x 64kB, 2048
>> x 32 kB and so forth, we need new memory stats either way.
>>
>> Ryan had some ideas on that, but currently, that's considered future work,
>> just like it likely is for the pagecache as well and needs much more
>> thoughts.
>>
>> Initially, the admin will have to enable all that for anon either way. It
>> all boils down to one memory statistic for anon memory (AnonHugePages)
. >> that's messed-up already.
>
> So we have FileHugePages which is very carefully only PMD-sized large
> folios. If people start making AnonHugePages count non-PMD-sized
> large folios, that's going to be inconsistent.
Right, and that's why we decided to leave these counters alone for now
and rather document that they only apply to PMD-sized THP for historical
reasons.
We'll want new stats either way. Hopefully we'll make it more
future-proof this time.
>
>>> am objecting to the use of the term "small THP" on the grounds of
>>> confusion and linguistic nonsense.
>>
>> Maybe that's the reason why FreeBSD calls them "medium-sized superpages",
>> because "Medium-sized" seems to be more appropriate to express something "in
>> between".
>
> I don't mind "medium" in the name.
>
>> So far I thought the reason was because they focused on 64k only.
>>
>> Never trust a German guy on naming suggestions. John has so far been my
>> naming expert, so I'm hoping he can help.
>>
>> "Sub-pmd-sized THP" is just mouthful. But then, again, this is would just be
>> a temporary name, and in the future THP will just naturally come in multiple
>> sizes (and others here seem to agree on that).
>
> I do not. If we'd come to this fifteen years ago, maybe, but people now
> have an understanding that THPs are necessarily PMD sized.
Well, I still find people being confused about THP vs. hugetlb, so
likely some confusion is unavoidable. :)
In your other mail you write "Perhaps the problem is that people have
turned "THP" into a thing in its own right."
I think that's exactly the case, and I see how that can be confusing
when spelling out THP and reading "small-huge: does it cancel out?".
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists