From: Vineet Gupta <vineetg@rivosinc.com>
To: "Christoph Müllner" <christoph.muellner@vrull.eu>,
"Palmer Dabbelt" <palmer@dabbelt.com>
Cc: libc-alpha@sourceware.org, adhemerval.zanella@linaro.org,
Darius Rad <darius@bluespec.com>,
Andrew Waterman <andrew@sifive.com>,
philipp.tomsich@vrull.eu, Evan Green <evan@rivosinc.com>,
kito.cheng@sifive.com, jeffreyalaw@gmail.com
Subject: Re: [RFC PATCH 3/3] RISC-V: Implement CPU yielding for busy loops with Zihintpause/Zawrs
Date: Thu, 18 Apr 2024 13:36:32 -0700 [thread overview]
Message-ID: <46e0cfcc-db0f-46fd-8e3f-707fbf656531@rivosinc.com> (raw)
In-Reply-To: <CAEg0e7gXi15=85-9sc7Ap+K8_AArGBkNsFixAjjYiCNQA3im=g@mail.gmail.com>
On 4/18/24 13:19, Christoph Müllner wrote:
>> This has the same forward progress/eventual success violation as the
>> code you sent for GCC and Linux does. It doesn't really matter if the
>> user of the reservation is in a builtin, an asm block, or a function.
>> The compiler just doesn't know about those reservation rules and isn't
>> going to generate code that follows them.
> I see. The main issue is that we don't have a valid reservation when
> calling WRS,
> so the whole use of Zawrs instructions is pointless.
> So the only way to move Zawrs forward would be to adjust the locking routines
> (introducing new primitives that have to be implemented for all architectures).
Not explicitly anyways - the generic fallback will take care of every
arch, except SPARC/x86 which implement atomic_spin_nop wth pause like
semantics, but even they don't need to change at all if we implement new
API atomic_load_and_spin_if_cond_whatever () in terms of existing
atomic_spin_nop ()
-Vineet
next prev parent reply other threads:[~2024-04-18 20:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-18 9:46 [RFC PATCH 0/3] RISC-V: Use WRS.STO for atomic_spin_nop Christoph Müllner
2024-04-18 9:46 ` [RFC PATCH 1/3] RISC-V: Sync hwprobe: Sync extension bits with Linux 6.8 Christoph Müllner
2024-04-18 9:46 ` [RFC PATCH 2/3] RISC-V: hwprobe: Add Zawrs test bit Christoph Müllner
2024-04-18 9:46 ` [RFC PATCH 3/3] RISC-V: Implement CPU yielding for busy loops with Zihintpause/Zawrs Christoph Müllner
2024-04-18 17:17 ` Palmer Dabbelt
2024-04-18 20:03 ` Vineet Gupta
2024-04-18 20:25 ` Christoph Müllner
2024-04-18 20:19 ` Christoph Müllner
2024-04-18 20:36 ` Vineet Gupta [this message]
2024-04-18 21:10 ` Palmer Dabbelt
2024-04-19 14:09 ` Andrew Jones
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=46e0cfcc-db0f-46fd-8e3f-707fbf656531@rivosinc.com \
--to=vineetg@rivosinc.com \
--cc=adhemerval.zanella@linaro.org \
--cc=andrew@sifive.com \
--cc=christoph.muellner@vrull.eu \
--cc=darius@bluespec.com \
--cc=evan@rivosinc.com \
--cc=jeffreyalaw@gmail.com \
--cc=kito.cheng@sifive.com \
--cc=libc-alpha@sourceware.org \
--cc=palmer@dabbelt.com \
--cc=philipp.tomsich@vrull.eu \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).