From: David Hildenbrand <david@redhat.com>
To: Ryan Roberts <ryan.roberts@arm.com>, Barry Song <baohua@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, Jonathan Corbet <corbet@lwn.net>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Lance Yang <ioworker0@gmail.com>,
Matthew Wilcox <willy@infradead.org>, Zi Yan <ziy@nvidia.com>,
Daniel Gomez <da.gomez@samsung.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v1] mm: shmem: Rename mTHP shmem counters
Date: Mon, 8 Jul 2024 22:50:30 +0200 [thread overview]
Message-ID: <10b201b1-53d3-4f62-be8e-996aa95d2b99@redhat.com> (raw)
In-Reply-To: <744749c3-4506-40d9-ac48-0dbc59689f92@arm.com>
On 08.07.24 14:29, Ryan Roberts wrote:
> On 08/07/2024 12:36, Barry Song wrote:
>> On Mon, Jul 8, 2024 at 11:24 PM Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>
>>> The legacy PMD-sized THP counters at /proc/vmstat include
>>> thp_file_alloc, thp_file_fallback and thp_file_fallback_charge, which
>>> rather confusingly refer to shmem THP and do not include any other types
>>> of file pages. This is inconsistent since in most other places in the
>>> kernel, THP counters are explicitly separated for anon, shmem and file
>>> flavours. However, we are stuck with it since it constitutes a user ABI.
>>>
>>> Recently, commit 66f44583f9b6 ("mm: shmem: add mTHP counters for
>>> anonymous shmem") added equivalent mTHP stats for shmem, keeping the
>>> same "file_" prefix in the names. But in future, we may want to add
>>> extra stats to cover actual file pages, at which point, it would all
>>> become very confusing.
>>>
>>> So let's take the opportunity to rename these new counters "shmem_"
>>> before the change makes it upstream and the ABI becomes immutable.
>>
>> Personally, I think this approach is much clearer. However, I recall
>> we discussed this
>> before [1], and it seems that inconsistency is a concern?
>
> Embarrassingly, I don't recall that converstation at all :-| but at least what I
> said then is consistent with what I've done in this patch.
>
> I think David's conclusion from that thread was to call them FILE_, and add both
> shmem and pagecache counts to those counters, meaning we can keep the same name
> as legacy THP counters. But those legacy THP counters only count shmem, and I
> don't think we would get away with adding pagecache counts to those at this
> point? (argument: they have been around for long time and there is a risk that
> user space relies on them and if they were to dramatically increase due to
> pagecache addition now that could break things). In that case, there is still
> inconsistency, but its worse; the names are consistent but the semantics are
> inconsistent.
>
> So my vote is to change to SHMEM_ as per this patch :)
I also forgot most of the discussion, but these 3 legacy counters are
really only (currently) incremented for shmem. I think my idea was to
keep everything as FILE_ for now, maybe at some point make the pagecache
also use them, and then maybe have separate FILE_ + SHMEM_.
But yeah, likely it's best to only have "shmem" here for now, because
who knows what we can actually change about the legacy counters. But
it's always though messing with legacy stuff that is clearly suboptimal ...
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-07-08 20:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-08 11:24 [PATCH v1] mm: shmem: Rename mTHP shmem counters Ryan Roberts
2024-07-08 11:36 ` Barry Song
2024-07-08 12:29 ` Ryan Roberts
2024-07-08 20:50 ` David Hildenbrand [this message]
2024-07-09 1:21 ` Lance Yang
2024-07-09 7:47 ` Ryan Roberts
2024-07-09 7:54 ` David Hildenbrand
2024-07-09 7:59 ` Ryan Roberts
2024-07-09 1:07 ` Baolin Wang
2024-07-09 1:44 ` Barry Song
2024-07-09 7:55 ` Ryan Roberts
2024-07-09 8:13 ` Barry Song
2024-07-09 8:35 ` Ryan Roberts
2024-07-09 8:40 ` Barry Song
2024-07-09 1:26 ` Lance Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10b201b1-53d3-4f62-be8e-996aa95d2b99@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=corbet@lwn.net \
--cc=da.gomez@samsung.com \
--cc=hughd@google.com \
--cc=ioworker0@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryan.roberts@arm.com \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox