All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Parri <parri.andrea@gmail.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Matthew Wilcox <willy@infradead.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Will Deacon <will@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	David Howells <dhowells@redhat.com>,
	Jade Alglave <j.alglave@ucl.ac.uk>,
	Luc Maranget <luc.maranget@inria.fr>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	linux-mm@kvack.org
Subject: Re: [RFC PATCH] mm: Add missing release barrier on PGDAT_RECLAIM_LOCKED unlock
Date: Wed, 12 Mar 2025 11:56:10 +0100	[thread overview]
Message-ID: <Z9FoSjoK3qCtJ6R5@andrea> (raw)
In-Reply-To: <20250307193047.66079-1-mathieu.desnoyers@efficios.com>

On Fri, Mar 07, 2025 at 02:30:47PM -0500, Mathieu Desnoyers wrote:
> The PGDAT_RECLAIM_LOCKED bit is used to provide mutual exclusion of
> node reclaim for struct pglist_data using a single bit.
> 
> It is "locked" with a test_and_set_bit (similarly to a try lock) which
> provides full ordering with respect to loads and stores done within
> __node_reclaim().
> 
> It is "unlocked" with clear_bit(), which does not provide any ordering
> with respect to loads and stores done before clearing the bit.
> 
> The lack of clear_bit() memory ordering with respect to stores within
> __node_reclaim() can cause a subsequent CPU to fail to observe stores
> from a prior node reclaim. This is not an issue in practice on TSO (e.g.
> x86), but it is an issue on weakly-ordered architectures (e.g. arm64).
> 
> Fix this with following changes:
> 
> A) Use clear_bit_unlock rather than clear_bit to clear PGDAT_RECLAIM_LOCKED
>    with a release memory ordering semantic.
> 
> This provides stronger memory ordering (release rather than relaxed).
> 
> B) Use test_and_set_bit_lock rather than test_and_set_bit to test-and-set
>    PGDAT_RECLAIM_LOCKED with an acquire memory ordering semantic.
> 
> This changes the "lock" acquisition from a full barrier to an acquire
> memory ordering, which is weaker. The acquire semi-permeable barrier
> paired with the release on unlock is sufficient for this mutual
> exclusion use-case.

FWIW, this aligns with my understanding.

Is (A) intended to be (submitted separately and) backported?

  Andrea


> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Andrea Parri <parri.andrea@gmail.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Boqun Feng <boqun.feng@gmail.com>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Jade Alglave <j.alglave@ucl.ac.uk>
> Cc: Luc Maranget <luc.maranget@inria.fr>
> Cc: "Paul E. McKenney" <paulmck@kernel.org>
> Cc: linux-mm@kvack.org
> ---
>  mm/vmscan.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index c22175120f5d..021b25bdba91 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -7567,11 +7567,11 @@ int node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned int order)
>  	if (node_state(pgdat->node_id, N_CPU) && pgdat->node_id != numa_node_id())
>  		return NODE_RECLAIM_NOSCAN;
>  
> -	if (test_and_set_bit(PGDAT_RECLAIM_LOCKED, &pgdat->flags))
> +	if (test_and_set_bit_lock(PGDAT_RECLAIM_LOCKED, &pgdat->flags))
>  		return NODE_RECLAIM_NOSCAN;
>  
>  	ret = __node_reclaim(pgdat, gfp_mask, order);
> -	clear_bit(PGDAT_RECLAIM_LOCKED, &pgdat->flags);
> +	clear_bit_unlock(PGDAT_RECLAIM_LOCKED, &pgdat->flags);
>  
>  	if (ret)
>  		count_vm_event(PGSCAN_ZONE_RECLAIM_SUCCESS);
> -- 
> 2.25.1
> 


      reply	other threads:[~2025-03-12 10:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-07 19:30 [RFC PATCH] mm: Add missing release barrier on PGDAT_RECLAIM_LOCKED unlock Mathieu Desnoyers
2025-03-12 10:56 ` Andrea Parri [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=Z9FoSjoK3qCtJ6R5@andrea \
    --to=parri.andrea@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=boqun.feng@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=luc.maranget@inria.fr \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=npiggin@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.