linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


  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