From: "David Hildenbrand (Red Hat)" <david@kernel.org>
To: Gabriel Krisman Bertazi <krisman@suse.de>, linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, jack@suse.cz,
Mateusz Guzik <mjguzik@gmail.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
Michal Hocko <mhocko@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>,
Christoph Lameter <cl@gentwo.org>,
Andrew Morton <akpm@linux-foundation.org>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: [RFC PATCH 4/4] mm: Split a slow path for updating mm counters
Date: Mon, 1 Dec 2025 11:19:04 +0100 [thread overview]
Message-ID: <f4e43699-b0de-4923-a798-89522857bd1f@kernel.org> (raw)
In-Reply-To: <20251127233635.4170047-5-krisman@suse.de>
On 11/28/25 00:36, Gabriel Krisman Bertazi wrote:
> For cases where we know we are not coming from local context, there is
> no point in touching current when incrementing/decrementing the
> counters. Split this path into another helper to avoid this cost.
>
> Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
> ---
> arch/s390/mm/gmap_helpers.c | 4 ++--
> arch/s390/mm/pgtable.c | 4 ++--
> fs/exec.c | 2 +-
> include/linux/mm.h | 14 +++++++++++---
> kernel/events/uprobes.c | 2 +-
> mm/filemap.c | 2 +-
> mm/huge_memory.c | 22 +++++++++++-----------
> mm/khugepaged.c | 6 +++---
> mm/ksm.c | 2 +-
> mm/madvise.c | 2 +-
> mm/memory.c | 20 ++++++++++----------
> mm/migrate.c | 2 +-
> mm/migrate_device.c | 2 +-
> mm/rmap.c | 16 ++++++++--------
> mm/swapfile.c | 6 +++---
> mm/userfaultfd.c | 2 +-
> 16 files changed, 58 insertions(+), 50 deletions(-)
>
> diff --git a/arch/s390/mm/gmap_helpers.c b/arch/s390/mm/gmap_helpers.c
> index d4c3c36855e2..6d8498c56d08 100644
> --- a/arch/s390/mm/gmap_helpers.c
> +++ b/arch/s390/mm/gmap_helpers.c
> @@ -29,9 +29,9 @@
> static void ptep_zap_swap_entry(struct mm_struct *mm, swp_entry_t entry)
> {
> if (!non_swap_entry(entry))
> - dec_mm_counter(mm, MM_SWAPENTS);
> + dec_mm_counter_other(mm, MM_SWAPENTS);
> else if (is_migration_entry(entry))
> - dec_mm_counter(mm, mm_counter(pfn_swap_entry_folio(entry)));
> + dec_mm_counter_other(mm, mm_counter(pfn_swap_entry_folio(entry)));
> free_swap_and_cache(entry);
> }
>
> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
> index 0fde20bbc50b..021a04f958e5 100644
> --- a/arch/s390/mm/pgtable.c
> +++ b/arch/s390/mm/pgtable.c
> @@ -686,11 +686,11 @@ void ptep_unshadow_pte(struct mm_struct *mm, unsigned long saddr, pte_t *ptep)
> static void ptep_zap_swap_entry(struct mm_struct *mm, swp_entry_t entry)
> {
> if (!non_swap_entry(entry))
> - dec_mm_counter(mm, MM_SWAPENTS);
> + dec_mm_counter_other(mm, MM_SWAPENTS);
> else if (is_migration_entry(entry)) {
> struct folio *folio = pfn_swap_entry_folio(entry);
>
> - dec_mm_counter(mm, mm_counter(folio));
> + dec_mm_counter_other(mm, mm_counter(folio));
> }
> free_swap_and_cache(entry);
> }
> diff --git a/fs/exec.c b/fs/exec.c
> index 4298e7e08d5d..33d0eb00d315 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -137,7 +137,7 @@ static void acct_arg_size(struct linux_binprm *bprm, unsigned long pages)
> return;
>
> bprm->vma_pages = pages;
> - add_mm_counter(mm, MM_ANONPAGES, diff);
> + add_mm_counter_local(mm, MM_ANONPAGES, diff);
> }
>
> static struct page *get_arg_page(struct linux_binprm *bprm, unsigned long pos,
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 29de4c60ac6c..2db12280e938 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2689,7 +2689,7 @@ static inline unsigned long get_mm_counter_sum(struct mm_struct *mm, int member)
>
> void mm_trace_rss_stat(struct mm_struct *mm, int member);
>
> -static inline void add_mm_counter(struct mm_struct *mm, int member, long value)
> +static inline void add_mm_counter_local(struct mm_struct *mm, int member, long value)
> {
> if (READ_ONCE(current->mm) == mm)
> lazy_percpu_counter_add_fast(&mm->rss_stat[member], value);
> @@ -2698,9 +2698,17 @@ static inline void add_mm_counter(struct mm_struct *mm, int member, long value)
>
> mm_trace_rss_stat(mm, member);
> }
> +static inline void add_mm_counter_other(struct mm_struct *mm, int member, long value)
> +{
> + lazy_percpu_counter_add_atomic(&mm->rss_stat[member], value);
> +
> + mm_trace_rss_stat(mm, member);
> +}
>
> -#define inc_mm_counter(mm, member) add_mm_counter(mm, member, 1)
> -#define dec_mm_counter(mm, member) add_mm_counter(mm, member, -1)
> +#define inc_mm_counter_local(mm, member) add_mm_counter_local(mm, member, 1)
> +#define dec_mm_counter_local(mm, member) add_mm_counter_local(mm, member, -1)
> +#define inc_mm_counter_other(mm, member) add_mm_counter_other(mm, member, 1)
> +#define dec_mm_counter_other(mm, member) add_mm_counter_other(mm, member, -1)
I'd have thought that there is a local and !local version, whereby the
latter one would simply maintain the old name. The "_other()" sticks out
a bit.
E.g., cmpxch() vs. cmpxchg_local().
Or would "_remote()" better describe what "_other()" intends to do?
--
Cheers
David
next prev parent reply other threads:[~2025-12-01 10:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-27 23:36 [RFC PATCH 0/4] Optimize rss_stat initialization/teardown for single-threaded tasks Gabriel Krisman Bertazi
2025-11-27 23:36 ` [RFC PATCH 1/4] lib/percpu_counter: Split out a helper to insert into hotplug list Gabriel Krisman Bertazi
2025-11-27 23:36 ` [RFC PATCH 2/4] lib: Support lazy initialization of per-cpu counters Gabriel Krisman Bertazi
2025-11-27 23:36 ` [RFC PATCH 3/4] mm: Avoid percpu MM counters on single-threaded tasks Gabriel Krisman Bertazi
2025-11-27 23:36 ` [RFC PATCH 4/4] mm: Split a slow path for updating mm counters Gabriel Krisman Bertazi
2025-12-01 10:19 ` David Hildenbrand (Red Hat) [this message]
2025-11-28 13:30 ` [RFC PATCH 0/4] Optimize rss_stat initialization/teardown for single-threaded tasks Mathieu Desnoyers
2025-11-28 20:10 ` Jan Kara
2025-11-28 20:12 ` Mathieu Desnoyers
2025-11-29 5:57 ` Mateusz Guzik
2025-11-29 7:50 ` Mateusz Guzik
2025-12-01 10:38 ` Harry Yoo
2025-12-01 11:31 ` Mateusz Guzik
2025-12-01 14:47 ` Mathieu Desnoyers
2025-12-01 15:23 ` Gabriel Krisman Bertazi
2025-12-01 19:16 ` Harry Yoo
2025-12-03 11:02 ` Mateusz Guzik
2025-12-03 11:54 ` Mateusz Guzik
2025-12-03 14:36 ` Mateusz Guzik
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=f4e43699-b0de-4923-a798-89522857bd1f@kernel.org \
--to=david@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=dennis@kernel.org \
--cc=jack@suse.cz \
--cc=krisman@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhocko@kernel.org \
--cc=mjguzik@gmail.com \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=tj@kernel.org \
--cc=vbabka@suse.cz \
/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