From: Alexandre Ghiti <alex@ghiti.fr>
To: Andrea Parri <parri.andrea@gmail.com>,
Alexandre Ghiti <alexghiti@rivosinc.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Nathan Chancellor <nathan@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Waiman Long <longman@redhat.com>,
Boqun Feng <boqun.feng@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
Leonardo Bras <leobras@redhat.com>, Guo Ren <guoren@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-arch@vger.kernel.org,
Andrea Parri <andrea@rivosinc.com>
Subject: Re: [PATCH v2 04/10] riscv: Improve amocas.X use in cmpxchg()
Date: Thu, 4 Jul 2024 18:40:19 +0200 [thread overview]
Message-ID: <956d345e-9451-490f-93e7-32ccd5f07c2e@ghiti.fr> (raw)
In-Reply-To: <Zn1pqD7Aruo4XwN8@andrea>
On 27/06/2024 15:31, Andrea Parri wrote:
> On Wed, Jun 26, 2024 at 03:03:41PM +0200, Alexandre Ghiti wrote:
>> cmpxchg() uses amocas.X instructions from Zacas and Zabha but still uses
>> the LR/SC acquire/release semantics which require barriers.
>>
>> Let's improve that by using proper amocas acquire/release semantics in
>> order to avoid any of those barriers.
> I can't really parse this changelog...
>
>
>> Suggested-by: Andrea Parri <andrea@rivosinc.com>
>> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
>> ---
>> arch/riscv/include/asm/cmpxchg.h | 60 ++++++++++++++++++--------------
>> 1 file changed, 33 insertions(+), 27 deletions(-)
>>
>> diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
>> index b9a3fdcec919..3c65b00a0d36 100644
>> --- a/arch/riscv/include/asm/cmpxchg.h
>> +++ b/arch/riscv/include/asm/cmpxchg.h
>> @@ -105,7 +105,9 @@
>> * indicated by comparing RETURN with OLD.
>> */
>>
>> -#define __arch_cmpxchg_masked(sc_sfx, cas_sfx, prepend, append, r, p, o, n) \
>> +#define __arch_cmpxchg_masked(sc_sfx, cas_sfx, \
>> + sc_prepend, sc_append, \
>> + r, p, o, n) \
>> ({ \
>> __label__ no_zacas, zabha, end; \
>> \
>> @@ -129,7 +131,7 @@ no_zacas:; \
>> ulong __rc; \
>> \
>> __asm__ __volatile__ ( \
>> - prepend \
>> + sc_prepend \
>> "0: lr.w %0, %2\n" \
>> " and %1, %0, %z5\n" \
>> " bne %1, %z3, 1f\n" \
>> @@ -137,7 +139,7 @@ no_zacas:; \
>> " or %1, %1, %z4\n" \
>> " sc.w" sc_sfx " %1, %1, %2\n" \
>> " bnez %1, 0b\n" \
>> - append \
>> + sc_append \
>> "1:\n" \
>> : "=&r" (__retx), "=&r" (__rc), "+A" (*(__ptr32b)) \
>> : "rJ" ((long)__oldx), "rJ" (__newx), \
>> @@ -150,9 +152,7 @@ no_zacas:; \
>> zabha: \
>> if (IS_ENABLED(CONFIG_RISCV_ISA_ZABHA)) { \
>> __asm__ __volatile__ ( \
>> - prepend \
>> " amocas" cas_sfx " %0, %z2, %1\n" \
>> - append \
>> : "+&r" (r), "+A" (*(p)) \
>> : "rJ" (n) \
>> : "memory"); \
>> @@ -160,7 +160,9 @@ zabha: \
>> end:; \
>> })
>>
>> -#define __arch_cmpxchg(lr_sfx, sc_cas_sfx, prepend, append, r, p, co, o, n) \
>> +#define __arch_cmpxchg(lr_sfx, sc_sfx, cas_sfx, \
>> + sc_prepend, sc_append, \
>> + r, p, co, o, n) \
>> ({ \
>> __label__ zacas, end; \
>> register unsigned int __rc; \
>> @@ -172,12 +174,12 @@ end:; \
>> } \
>> \
>> __asm__ __volatile__ ( \
>> - prepend \
>> + sc_prepend \
>> "0: lr" lr_sfx " %0, %2\n" \
>> " bne %0, %z3, 1f\n" \
>> - " sc" sc_cas_sfx " %1, %z4, %2\n" \
>> + " sc" sc_sfx " %1, %z4, %2\n" \
>> " bnez %1, 0b\n" \
>> - append \
>> + sc_append \
>> "1:\n" \
>> : "=&r" (r), "=&r" (__rc), "+A" (*(p)) \
>> : "rJ" (co o), "rJ" (n) \
>> @@ -187,9 +189,7 @@ end:; \
>> zacas: \
>> if (IS_ENABLED(CONFIG_RISCV_ISA_ZACAS)) { \
>> __asm__ __volatile__ ( \
>> - prepend \
>> - " amocas" sc_cas_sfx " %0, %z2, %1\n" \
>> - append \
>> + " amocas" cas_sfx " %0, %z2, %1\n" \
>> : "+&r" (r), "+A" (*(p)) \
>> : "rJ" (n) \
>> : "memory"); \
>> @@ -197,7 +197,8 @@ zacas: \
>> end:; \
>> })
>>
>> -#define _arch_cmpxchg(ptr, old, new, sc_sfx, prepend, append) \
>> +#define _arch_cmpxchg(ptr, old, new, sc_sfx, cas_sfx, \
>> + sc_prepend, sc_append) \
>> ({ \
>> __typeof__(ptr) __ptr = (ptr); \
>> __typeof__(*(__ptr)) __old = (old); \
>> @@ -206,22 +207,24 @@ end:; \
>> \
>> switch (sizeof(*__ptr)) { \
>> case 1: \
>> - __arch_cmpxchg_masked(sc_sfx, ".b" sc_sfx, \
>> - prepend, append, \
>> - __ret, __ptr, __old, __new); \
>> + __arch_cmpxchg_masked(sc_sfx, ".b" cas_sfx, \
>> + sc_prepend, sc_append, \
>> + __ret, __ptr, __old, __new); \
>> break; \
>> case 2: \
>> - __arch_cmpxchg_masked(sc_sfx, ".h" sc_sfx, \
>> - prepend, append, \
>> - __ret, __ptr, __old, __new); \
>> + __arch_cmpxchg_masked(sc_sfx, ".h" cas_sfx, \
>> + sc_prepend, sc_append, \
>> + __ret, __ptr, __old, __new); \
>> break; \
>> case 4: \
>> - __arch_cmpxchg(".w", ".w" sc_sfx, prepend, append, \
>> - __ret, __ptr, (long), __old, __new); \
>> + __arch_cmpxchg(".w", ".w" sc_sfx, ".w" cas_sfx, \
>> + sc_prepend, sc_append, \
>> + __ret, __ptr, (long), __old, __new); \
>> break; \
>> case 8: \
>> - __arch_cmpxchg(".d", ".d" sc_sfx, prepend, append, \
>> - __ret, __ptr, /**/, __old, __new); \
>> + __arch_cmpxchg(".d", ".d" sc_sfx, ".d" cas_sfx, \
>> + sc_prepend, sc_append, \
>> + __ret, __ptr, /**/, __old, __new); \
>> break; \
>> default: \
>> BUILD_BUG(); \
>> @@ -230,16 +233,19 @@ end:; \
>> })
>>
>> #define arch_cmpxchg_relaxed(ptr, o, n) \
>> - _arch_cmpxchg((ptr), (o), (n), "", "", "")
>> + _arch_cmpxchg((ptr), (o), (n), "", "", "", "")
>>
>> #define arch_cmpxchg_acquire(ptr, o, n) \
>> - _arch_cmpxchg((ptr), (o), (n), "", "", RISCV_ACQUIRE_BARRIER)
>> + _arch_cmpxchg((ptr), (o), (n), "", ".aq", \
>> + "", RISCV_ACQUIRE_BARRIER)
>>
>> #define arch_cmpxchg_release(ptr, o, n) \
>> - _arch_cmpxchg((ptr), (o), (n), "", RISCV_RELEASE_BARRIER, "")
>> + _arch_cmpxchg((ptr), (o), (n), "", ".rl", \
>> + RISCV_RELEASE_BARRIER, "")
>>
>> #define arch_cmpxchg(ptr, o, n) \
>> - _arch_cmpxchg((ptr), (o), (n), ".rl", "", " fence rw, rw\n")
>> + _arch_cmpxchg((ptr), (o), (n), ".rl", ".aqrl", \
>> + "", RISCV_FULL_BARRIER)
> ... but this is not what I suggested: my suggestion [1] was about (limited
> to) the fully-ordered macro arch_cmpxchg(). In fact, I've recently raised
> some concern about similar changes to the acquire/release macros, cf. [2].
>
> Any particular reasons for doing this?
Not at all, I overinterpreted your suggestion, I'll restrict this to the
fully-ordered macro then.
Thanks,
>
> Andrea
>
> [1] https://lore.kernel.org/lkml/ZlYff9x12FICHoP0@andrea/
> [2] https://lore.kernel.org/lkml/20240505123340.38495-1-puranjay@kernel.org/
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-07-04 16:40 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-26 13:03 [PATCH v2 00/10] Zacas/Zabha support and qspinlocks Alexandre Ghiti
2024-06-26 13:03 ` [PATCH v2 01/10] riscv: Implement cmpxchg32/64() using Zacas Alexandre Ghiti
2024-06-27 11:06 ` Andrea Parri
2024-07-04 16:25 ` Alexandre Ghiti
2024-07-09 23:47 ` Andrea Parri
2024-07-15 11:48 ` Alexandre Ghiti
2024-07-04 3:38 ` kernel test robot
2024-07-05 17:27 ` Nathan Chancellor
2024-07-16 12:19 ` Alexandre Ghiti
2024-07-16 14:00 ` Nathan Chancellor
2024-06-26 13:03 ` [PATCH v2 02/10] dt-bindings: riscv: Add Zabha ISA extension description Alexandre Ghiti
2024-06-26 14:20 ` Krzysztof Kozlowski
2024-06-26 13:03 ` [PATCH v2 03/10] riscv: Implement cmpxchg8/16() using Zabha Alexandre Ghiti
2024-06-27 11:53 ` Andrea Parri
2024-06-29 19:19 ` Andrea Parri
2024-07-04 16:36 ` Alexandre Ghiti
2024-07-09 23:51 ` Andrea Parri
2024-07-15 12:56 ` Alexandre Ghiti
2024-06-26 13:03 ` [PATCH v2 04/10] riscv: Improve amocas.X use in cmpxchg() Alexandre Ghiti
2024-06-27 13:31 ` Andrea Parri
2024-07-04 16:40 ` Alexandre Ghiti [this message]
2024-06-26 13:03 ` [PATCH v2 05/10] riscv: Implement arch_cmpxchg128() using Zacas Alexandre Ghiti
2024-06-26 13:03 ` [PATCH v2 06/10] riscv: Implement xchg8/16() using Zabha Alexandre Ghiti
2024-06-27 13:45 ` Andrea Parri
2024-07-04 17:25 ` Alexandre Ghiti
2024-07-10 1:37 ` Guo Ren
2024-07-15 13:20 ` Alexandre Ghiti
2024-06-26 13:03 ` [PATCH v2 07/10] riscv: Improve amoswap.X use in xchg() Alexandre Ghiti
2024-06-27 13:58 ` Andrea Parri
2024-07-04 17:26 ` Alexandre Ghiti
2024-07-10 0:09 ` Andrea Parri
2024-06-26 13:03 ` [PATCH v2 08/10] asm-generic: ticket-lock: Reuse arch_spinlock_t of qspinlock Alexandre Ghiti
2024-06-26 13:03 ` [PATCH v2 09/10] asm-generic: ticket-lock: Add separate ticket-lock.h Alexandre Ghiti
2024-06-26 13:03 ` [PATCH v2 10/10] riscv: Add qspinlock support based on Zabha extension Alexandre Ghiti
2024-06-27 15:19 ` Andrea Parri
2024-07-04 17:33 ` Alexandre Ghiti
2024-07-07 2:20 ` Guo Ren
2024-07-08 11:51 ` Guo Ren
2024-07-15 7:33 ` Alexandre Ghiti
2024-07-15 7:27 ` Alexandre Ghiti
2024-07-15 19:30 ` Waiman Long
2024-07-16 1:04 ` Guo Ren
2024-07-16 6:43 ` Alexandre Ghiti
2024-07-16 8:31 ` Guo Ren
2024-07-17 6:19 ` Alexandre Ghiti
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=956d345e-9451-490f-93e7-32ccd5f07c2e@ghiti.fr \
--to=alex@ghiti.fr \
--cc=alexghiti@rivosinc.com \
--cc=andrea@rivosinc.com \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=boqun.feng@gmail.com \
--cc=corbet@lwn.net \
--cc=guoren@kernel.org \
--cc=leobras@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=nathan@kernel.org \
--cc=palmer@dabbelt.com \
--cc=parri.andrea@gmail.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.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;
as well as URLs for NNTP newsgroup(s).