linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lance Yang <ioworker0@gmail.com>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>,
	 Jonathan Corbet <corbet@lwn.net>, Barry Song <baohua@kernel.org>,
	David Hildenbrand <david@redhat.com>,
	 Baolin Wang <baolin.wang@linux.alibaba.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: Tue, 9 Jul 2024 09:26:48 +0800	[thread overview]
Message-ID: <CAK1f24nnJKysBi9N=p-Lf9yfQv0+Z3AY2+F2u3vC+e5yvW3yvQ@mail.gmail.com> (raw)
In-Reply-To: <20240708112445.2690631-1-ryan.roberts@arm.com>

On Mon, Jul 8, 2024 at 7: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.
>
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>

LGTM. Feel free to add:
Reviewed-by: Lance Yang <ioworker0@gmail.com>

Thanks,
Lance

> ---
>
> Hi All,
>
> Applies on top of today's mm-unstable (2073cda629a4) and tested with mm
> selftests; no regressions observed.
>
> The backstory here is that I'd like to introduce some counters for regular file
> folio allocations to observe how often large folio allocation succeeds, but
> these shmem counters are named "file" which is going to make things confusing.
> So hoping to solve that before commit 66f44583f9b6 ("mm: shmem: add mTHP
> counters for anonymous shmem") goes upstream (it is currently in mm-stable).
>
> Admittedly, this change means the mTHP stat names are not the same as the legacy
> PMD-size THP names, but I think that's a smaller issue than having "file_" mTHP
> stats that only count shmem, then having to introduce "file2_" or "pgcache_"
> stats for the regular file memory, which is even more inconsistent IMHO. I guess
> the alternative is to count both shmem and file in these mTHP stats (that's how
> they were documented anyway) but I think it's better to be able to consider them
> separately like we do for all the other counters.
>
> Thanks,
> Ryan
>
>  Documentation/admin-guide/mm/transhuge.rst | 12 ++++++------
>  include/linux/huge_mm.h                    |  6 +++---
>  mm/huge_memory.c                           | 12 ++++++------
>  mm/shmem.c                                 |  8 ++++----
>  4 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
> index 747c811ee8f1..8b891689fc13 100644
> --- a/Documentation/admin-guide/mm/transhuge.rst
> +++ b/Documentation/admin-guide/mm/transhuge.rst
> @@ -496,16 +496,16 @@ swpout_fallback
>         Usually because failed to allocate some continuous swap space
>         for the huge page.
>
> -file_alloc
> -       is incremented every time a file huge page is successfully
> +shmem_alloc
> +       is incremented every time a shmem huge page is successfully
>         allocated.
>
> -file_fallback
> -       is incremented if a file huge page is attempted to be allocated
> +shmem_fallback
> +       is incremented if a shmem huge page is attempted to be allocated
>         but fails and instead falls back to using small pages.
>
> -file_fallback_charge
> -       is incremented if a file huge page cannot be charged and instead
> +shmem_fallback_charge
> +       is incremented if a shmem huge page cannot be charged and instead
>         falls back to using small pages even though the allocation was
>         successful.
>
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index acb6ac24a07e..cff002be83eb 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -269,9 +269,9 @@ enum mthp_stat_item {
>         MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE,
>         MTHP_STAT_SWPOUT,
>         MTHP_STAT_SWPOUT_FALLBACK,
> -       MTHP_STAT_FILE_ALLOC,
> -       MTHP_STAT_FILE_FALLBACK,
> -       MTHP_STAT_FILE_FALLBACK_CHARGE,
> +       MTHP_STAT_SHMEM_ALLOC,
> +       MTHP_STAT_SHMEM_FALLBACK,
> +       MTHP_STAT_SHMEM_FALLBACK_CHARGE,
>         MTHP_STAT_SPLIT,
>         MTHP_STAT_SPLIT_FAILED,
>         MTHP_STAT_SPLIT_DEFERRED,
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 9ec64aa2be94..f9696c94e211 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -568,9 +568,9 @@ DEFINE_MTHP_STAT_ATTR(anon_fault_fallback, MTHP_STAT_ANON_FAULT_FALLBACK);
>  DEFINE_MTHP_STAT_ATTR(anon_fault_fallback_charge, MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE);
>  DEFINE_MTHP_STAT_ATTR(swpout, MTHP_STAT_SWPOUT);
>  DEFINE_MTHP_STAT_ATTR(swpout_fallback, MTHP_STAT_SWPOUT_FALLBACK);
> -DEFINE_MTHP_STAT_ATTR(file_alloc, MTHP_STAT_FILE_ALLOC);
> -DEFINE_MTHP_STAT_ATTR(file_fallback, MTHP_STAT_FILE_FALLBACK);
> -DEFINE_MTHP_STAT_ATTR(file_fallback_charge, MTHP_STAT_FILE_FALLBACK_CHARGE);
> +DEFINE_MTHP_STAT_ATTR(shmem_alloc, MTHP_STAT_SHMEM_ALLOC);
> +DEFINE_MTHP_STAT_ATTR(shmem_fallback, MTHP_STAT_SHMEM_FALLBACK);
> +DEFINE_MTHP_STAT_ATTR(shmem_fallback_charge, MTHP_STAT_SHMEM_FALLBACK_CHARGE);
>  DEFINE_MTHP_STAT_ATTR(split, MTHP_STAT_SPLIT);
>  DEFINE_MTHP_STAT_ATTR(split_failed, MTHP_STAT_SPLIT_FAILED);
>  DEFINE_MTHP_STAT_ATTR(split_deferred, MTHP_STAT_SPLIT_DEFERRED);
> @@ -581,9 +581,9 @@ static struct attribute *stats_attrs[] = {
>         &anon_fault_fallback_charge_attr.attr,
>         &swpout_attr.attr,
>         &swpout_fallback_attr.attr,
> -       &file_alloc_attr.attr,
> -       &file_fallback_attr.attr,
> -       &file_fallback_charge_attr.attr,
> +       &shmem_alloc_attr.attr,
> +       &shmem_fallback_attr.attr,
> +       &shmem_fallback_charge_attr.attr,
>         &split_attr.attr,
>         &split_failed_attr.attr,
>         &split_deferred_attr.attr,
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 921d59c3d669..f24dfbd387ba 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1777,7 +1777,7 @@ static struct folio *shmem_alloc_and_add_folio(struct vm_fault *vmf,
>                         if (pages == HPAGE_PMD_NR)
>                                 count_vm_event(THP_FILE_FALLBACK);
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> -                       count_mthp_stat(order, MTHP_STAT_FILE_FALLBACK);
> +                       count_mthp_stat(order, MTHP_STAT_SHMEM_FALLBACK);
>  #endif
>                         order = next_order(&suitable_orders, order);
>                 }
> @@ -1804,8 +1804,8 @@ static struct folio *shmem_alloc_and_add_folio(struct vm_fault *vmf,
>                                 count_vm_event(THP_FILE_FALLBACK_CHARGE);
>                         }
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> -                       count_mthp_stat(folio_order(folio), MTHP_STAT_FILE_FALLBACK);
> -                       count_mthp_stat(folio_order(folio), MTHP_STAT_FILE_FALLBACK_CHARGE);
> +                       count_mthp_stat(folio_order(folio), MTHP_STAT_SHMEM_FALLBACK);
> +                       count_mthp_stat(folio_order(folio), MTHP_STAT_SHMEM_FALLBACK_CHARGE);
>  #endif
>                 }
>                 goto unlock;
> @@ -2181,7 +2181,7 @@ static int shmem_get_folio_gfp(struct inode *inode, pgoff_t index,
>                         if (folio_test_pmd_mappable(folio))
>                                 count_vm_event(THP_FILE_ALLOC);
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> -                       count_mthp_stat(folio_order(folio), MTHP_STAT_FILE_ALLOC);
> +                       count_mthp_stat(folio_order(folio), MTHP_STAT_SHMEM_ALLOC);
>  #endif
>                         goto alloced;
>                 }
> --
> 2.43.0
>


      parent reply	other threads:[~2024-07-09  1:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-08 11:24 Ryan Roberts
2024-07-08 11:36 ` Barry Song
2024-07-08 12:29   ` Ryan Roberts
2024-07-08 20:50     ` David Hildenbrand
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 [this message]

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='CAK1f24nnJKysBi9N=p-Lf9yfQv0+Z3AY2+F2u3vC+e5yvW3yvQ@mail.gmail.com' \
    --to=ioworker0@gmail.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=david@redhat.com \
    --cc=hughd@google.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