> Whatever the name is, do you contend that store-before-load/store is
> _useful_? Can you show why? And, can you show an architecture where
> it's actually cheaper than membar_sync?
The first two are good questions. (I don't have an answer to them, but
I haven't had much to say on this
> Date: Fri, 11 Feb 2022 15:47:01 -0800
> From: Jason Thorpe
>
> My beef with the membar_enter definitional change is with the word
> "acquire". I.e. you want to give it what is called today "acquire"
> semantics. My beef is with now "acquire" is defined, as
> load-before-load/store.
Whatever
> On Feb 11, 2022, at 10:27 AM, Taylor R Campbell wrote:
>
> So x86, powerpc, and sparc64 all implement what I suggest membar_enter
> _should_ be (and what all current users use it for!), and _fail_ to
> implement what membar_enter is documented to be in the man page.
>
> And of all the
> Date: Fri, 11 Feb 2022 09:29:39 -0800
> From: Jason Thorpe
>
> > On Feb 11, 2022, at 9:03 AM, Jason Thorpe wrote:
> >
> > Right, v7 didn't have any barrier instructions, and v8 only had
> > STBAR (a stores-before-stores barrier), IIRC. I did not realize
> > we are using RMO for 64-bit
> On Feb 11, 2022, at 9:03 AM, Jason Thorpe wrote:
>
>
>> On Feb 11, 2022, at 8:45 AM, Martin Husemann wrote:
>>
>> so Jason is correct. For userland we default to RMO for 64bit binaries
>> (but honor their elf flags), and TSO for 32bit.
>
> Right, v7 didn't have any barrier instructions,
> On Feb 11, 2022, at 8:45 AM, Martin Husemann wrote:
>
> so Jason is correct. For userland we default to RMO for 64bit binaries
> (but honor their elf flags), and TSO for 32bit.
Right, v7 didn't have any barrier instructions, and v8 only had STBAR (a
stores-before-stores barrier), IIRC. I
On Fri, Feb 11, 2022 at 11:33:39AM -0500, Mouse wrote:
> >> sparc64: [...]
> > Almost forgot to mention ... I wouldn't read too much into how sparc64's
> > bar$
>
> Is that choice run-time configurable? I thought it was baked into the
> hardware...but admittedly that's based on documents I read
>> sparc64: [...]
> Almost forgot to mention ... I wouldn't read too much into how sparc64's bar$
Is that choice run-time configurable? I thought it was baked into the
hardware...but admittedly that's based on documents I read Quite Some
Time Ago.
/~\ The ASCII Mouse
> On Feb 11, 2022, at 5:33 AM, Taylor R Campbell wrote:
>
> sparc64: alias for membar_sync (not sure membar #LoadLoad is right, though!)
Almost forgot to mention ... I wouldn't read too much into how sparc64's
barriers are implemented ... I'm pretty sure our sparc64 port configures the
> On Feb 11, 2022, at 7:07 AM, Taylor R Campbell wrote:
>
>> Date: Fri, 11 Feb 2022 06:52:48 -0800
>> From: Jason Thorpe
>>
>> I would prefer we adopt the Solaris description about a generic
>> barrier that provides "lock-is-visible-before-load/store" without
>> explicitly stating
> Date: Fri, 11 Feb 2022 06:52:48 -0800
> From: Jason Thorpe
>
> I would prefer we adopt the Solaris description about a generic
> barrier that provides "lock-is-visible-before-load/store" without
> explicitly stating "load-before-load/store", and provide a new
> membar_acquire() that means
> On Feb 11, 2022, at 5:33 AM, Taylor R Campbell wrote:
>
> So I propose to change the membar_enter documentation to match the
> definitions and usage (and change the riscv definition), making it
> instead:
>
> membar_enter()
> Any load preceding membar_enter() will happen
> On Feb 11, 2022, at 5:33 AM, Taylor R Campbell wrote:
>
> The following definitions provide load-before-load/store:
>
> aarch64: alias for membar_sync
> alpha: alias for membar_sync
> arm: alias for membar_sync
Actually, on Alpha[*], an alias to membar_sync is really providing
membar_enter is currently documented to be a store-before-load/store
barrier: https://man.netbsd.org/NetBSD-9.2/membar_ops.3
membar_enter()
Any store preceding membar_enter() will happen before all memory
operations following it.
Prompted by the use of membar_enter in
14 matches
Mail list logo
