linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Christoph Lameter (Ampere)" <cl@gentwo.org>
To: Waiman Long <longman@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	 Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	 Boqun Feng <boqun.feng@gmail.com>,
	 Linus Torvalds <torvalds@linux-foundation.org>,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC] Avoid memory barrier in read_seqcount() through load acquire
Date: Tue, 13 Aug 2024 12:41:11 -0700 (PDT)	[thread overview]
Message-ID: <147572ea-c5ae-7992-6015-3181f10a785e@gentwo.org> (raw)
In-Reply-To: <183ee6fa-1d42-4a01-8446-4f20942680d2@redhat.com>

On Tue, 13 Aug 2024, Waiman Long wrote:

> Do we need a new ARCH flag? I believe barrier APIs like smp_load_acquire() 
> will use the full barrier for those arch'es that don't define their own 
> smp_load_acquire().

Well this is a load acquire instruction. The fallback of smp_load_aquire 
is:

#define __smp_load_acquire(p)                                           \
({                                                                      \
         __unqual_scalar_typeof(*p) ___p1 = READ_ONCE(*p);               \
         compiletime_assert_atomic_type(*p);                             \
         __smp_mb();                                                     \
         (typeof(*p))___p1;                                              \
})

Looks like we have an acquire + barrier here.

> BTW, acquire/release can be considered memory barriers too. Maybe you are 
> talking about preferring acquire/release barriers over read/write barriers. 
> Right?

Load acquire is a single instruction load that does not require full 
barrier semantics for the critical section but ensures that the value is 
loaded before all following. Regular barriers do not have this singe load 
that isolates the critical section and sequence all loads around them.



  reply	other threads:[~2024-08-13 19:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-13 18:26 Christoph Lameter via B4 Relay
2024-08-13 19:01 ` Waiman Long
2024-08-13 19:41   ` Christoph Lameter (Ampere) [this message]
2024-08-13 19:48   ` Linus Torvalds
2024-08-13 19:58     ` Waiman Long
2024-08-13 20:01       ` Linus Torvalds
2024-08-13 20:23         ` Waiman Long
2024-08-19  8:45 ` Mark Rutland
2024-08-19 16:25   ` Linus Torvalds

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=147572ea-c5ae-7992-6015-3181f10a785e@gentwo.org \
    --to=cl@gentwo.org \
    --cc=boqun.feng@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox