> Date: Sat, 12 Mar 2022 10:42:18 +
> From: Taylor R Campbell
>
> - The one-word difference is immaterial for ordering atomic-r/m/w and
> then load/store (or, equivalently, ll/sc and then load/store) -- so
> the change doesn't affect mutex_enter-type operations implemented
> with,
On Mon, Feb 14, 2022 at 08:11:57AM +, Taylor R Campbell wrote:
> > On Fri, Feb 11, 2022 at 01:33:04PM +, Taylor R Campbell wrote:
> > > membar_enter is currently documented to be a store-before-load/store
> > > barrier: https://man.netbsd.org/NetBSD-9.2/membar_ops.3
> > >
> > >
(sorry, lost track of this)
On Mon, Feb 14, 2022 at 05:12:13AM +0100, Joerg Sonnenberger wrote:
> Am Mon, Feb 14, 2022 at 02:45:46AM + schrieb David Holland:
> > On Mon, Feb 14, 2022 at 03:12:29AM +0100, Joerg Sonnenberger wrote:
> > > Am Mon, Feb 14, 2022 at 02:01:13AM + schrieb
Ping? Is your objection still standing? If yes, can you address my
responses?
Recap:
- Proposal is to change one word in the membar_enter man page from
Any store preceding membar_enter() will happen before all memory
operations following it.
to
Any load
> Date: Tue, 15 Feb 2022 12:54:09 +0100
> From: Edgar Fuß
>
> If there's a widely adopted terminology, one should probably stick
> to it even if the wording is counter-intuitive or misleading (but
> note that fact in the documentation). After all, Simple Groups are
> not easy at all and you need
I know close to nothing about the subject in question, but maybe thoughts from
a non-expert may be useful:
If there's a widely adopted terminology, one should probably stick to it even
if the wording is counter-intuitive or misleading (but note that fact in the
documentation). After all,
> Date: Mon, 14 Feb 2022 02:01:13 +
> From: David Holland
>
> On Fri, Feb 11, 2022 at 01:33:04PM +, Taylor R Campbell wrote:
> > membar_enter is currently documented to be a store-before-load/store
> > barrier: https://man.netbsd.org/NetBSD-9.2/membar_ops.3
> >
> >
Am Mon, Feb 14, 2022 at 02:45:46AM + schrieb David Holland:
> On Mon, Feb 14, 2022 at 03:12:29AM +0100, Joerg Sonnenberger wrote:
> > Am Mon, Feb 14, 2022 at 02:01:13AM + schrieb David Holland:
> > > In this case I would argue that the names should be membar_load_any()
> > > and
On Mon, Feb 14, 2022 at 03:12:29AM +0100, Joerg Sonnenberger wrote:
> Am Mon, Feb 14, 2022 at 02:01:13AM + schrieb David Holland:
> > In this case I would argue that the names should be membar_load_any()
> > and membar_any_store().
>
> Kind of like with the BUSDMA_* flags, it is not
Am Mon, Feb 14, 2022 at 02:01:13AM + schrieb David Holland:
> In this case I would argue that the names should be membar_load_any()
> and membar_any_store().
Kind of like with the BUSDMA_* flags, it is not clear from that name in
which direction they work either. As in: is it a barrier that
On Fri, Feb 11, 2022 at 01:33:04PM +, Taylor R Campbell wrote:
> 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
> 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
mbar_enter() will happen before all memory
> operations following it.
>
> This will also let us delete the obnoxious text I added to
> atomic_loadstore(9) warning about membar_enter semantics.
I would prefer we adopt the Solaris description about a generic barrier that
provide
> 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
nition), making it
instead:
membar_enter()
Any load preceding membar_enter() will happen before all memory
operations following it.
This will also let us delete the obnoxious text I added to
atomic_loadstore(9) warning about membar_enter semantics.
Thoughts?
* Defin
25 matches
Mail list logo
