From: Palmer Dabbelt <palmer@dabbelt.com>
To: Vineet Gupta <vineetg@rivosinc.com>,
ajones@ventanamicro.com, Charlie Jenkins <charlie@rivosinc.com>
Cc: christoph.muellner@vrull.eu, 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 14:10:42 -0700 (PDT) [thread overview]
Message-ID: <mhng-ef7207ca-8d8f-441d-9fe5-bc9d766fbb0a@palmer-ri-x1c9a> (raw)
In-Reply-To: <46e0cfcc-db0f-46fd-8e3f-707fbf656531@rivosinc.com>
On Thu, 18 Apr 2024 13:36:32 PDT (-0700), Vineet Gupta wrote:
> 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 ()
Ya, sounds about right.
IIRC I just hooked some of the LLL macros when doing the POC/estimates,
but it was at least a year ago so I forget exactly how it all fit
together. Whatever it is, they end up with basically the same
load->cond->lr->beq->{wrs,sc} patterns as a bunch of the Linux routines
should have (sort of a test-and-test-and-set type pattern, or how arm64
does the load-and-cmpxchg routines).
Adding Charlie and Drew, as we were talking about the Linux side of
things recently.
> -Vineet
next prev parent reply other threads:[~2024-04-18 21:10 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
2024-04-18 21:10 ` Palmer Dabbelt [this message]
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=mhng-ef7207ca-8d8f-441d-9fe5-bc9d766fbb0a@palmer-ri-x1c9a \
--to=palmer@dabbelt.com \
--cc=adhemerval.zanella@linaro.org \
--cc=ajones@ventanamicro.com \
--cc=andrew@sifive.com \
--cc=charlie@rivosinc.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=philipp.tomsich@vrull.eu \
--cc=vineetg@rivosinc.com \
/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).