On Thu, Sep 27, 2018 at 09:17:47AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 26, 2018 at 10:52:08PM +0200, Andrea Parri wrote:
> > On Wed, Sep 26, 2018 at 01:01:20PM +0200, Peter Zijlstra wrote:
> > > On x86 we cannot do fetch_or with a single instruction and end up
> >
On Thu, Sep 27, 2018 at 09:17:47AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 26, 2018 at 10:52:08PM +0200, Andrea Parri wrote:
> > On Wed, Sep 26, 2018 at 01:01:20PM +0200, Peter Zijlstra wrote:
> > > On x86 we cannot do fetch_or with a single instruction and end up
> >
On Wed, Sep 26, 2018 at 01:01:20PM +0200, Peter Zijlstra wrote:
> On x86 we cannot do fetch_or with a single instruction and end up
> using a cmpxchg loop, this reduces determinism. Replace the fetch_or
> with a very tricky composite xchg8 + load.
>
> The basic idea is that we use xchg8 to
On Wed, Sep 26, 2018 at 01:01:20PM +0200, Peter Zijlstra wrote:
> On x86 we cannot do fetch_or with a single instruction and end up
> using a cmpxchg loop, this reduces determinism. Replace the fetch_or
> with a very tricky composite xchg8 + load.
>
> The basic idea is that we use xchg8 to
On Tue, Sep 25, 2018 at 10:19:24AM -0700, Palmer Dabbelt wrote:
> On Tue, 25 Sep 2018 05:12:24 PDT (-0700), andrea.pa...@amarulasolutions.com
> wrote:
> > The barriers are unused; remove their definition.
> >
> > Signed-off-by: Andrea Parri
> > Cc: Palmer Dabb
On Tue, Sep 25, 2018 at 10:19:24AM -0700, Palmer Dabbelt wrote:
> On Tue, 25 Sep 2018 05:12:24 PDT (-0700), andrea.pa...@amarulasolutions.com
> wrote:
> > The barriers are unused; remove their definition.
> >
> > Signed-off-by: Andrea Parri
> > Cc: Palmer Dabb
The barriers are unused; remove their definition.
Signed-off-by: Andrea Parri
Cc: Palmer Dabbelt
Cc: Albert Ou
Cc:
---
arch/riscv/include/asm/bitops.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/riscv/include/asm/bitops.h b/arch/riscv/include/asm/bitops.h
index f30daf26f08f4
The barriers are unused; remove their definition.
Signed-off-by: Andrea Parri
Cc: Yoshinori Sato
Cc:
---
arch/h8300/include/asm/bitops.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/h8300/include/asm/bitops.h b/arch/h8300/include/asm/bitops.h
index 647a83bd40b70
The barriers are unused; remove their definition.
Signed-off-by: Andrea Parri
Cc: Palmer Dabbelt
Cc: Albert Ou
Cc:
---
arch/riscv/include/asm/bitops.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/riscv/include/asm/bitops.h b/arch/riscv/include/asm/bitops.h
index f30daf26f08f4
The barriers are unused; remove their definition.
Signed-off-by: Andrea Parri
Cc: Yoshinori Sato
Cc:
---
arch/h8300/include/asm/bitops.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/h8300/include/asm/bitops.h b/arch/h8300/include/asm/bitops.h
index 647a83bd40b70
A trivial clean-up, removing the (now obsolete) definitions of the two
barriers. (smp_mb__{before,after}_atomic() can serve similar purposes.)
Andrea
Cc: Yoshinori Sato
Cc:
Cc: Palmer Dabbelt
Cc: Albert Ou
Cc:
Andrea Parri (2):
riscv/bitops: Remove smp_mb__{before,after}_clear_bit
A trivial clean-up, removing the (now obsolete) definitions of the two
barriers. (smp_mb__{before,after}_atomic() can serve similar purposes.)
Andrea
Cc: Yoshinori Sato
Cc:
Cc: Palmer Dabbelt
Cc: Albert Ou
Cc:
Andrea Parri (2):
riscv/bitops: Remove smp_mb__{before,after}_clear_bit
Hi Guo,
> +/*
> + * set_bit - Atomically set a bit in memory
> + * @nr: the bit to set
> + * @addr: the address to start counting from
> + *
> + * This function is atomic and may not be reordered. See __set_bit()
> + * if you do not require the atomic guarantees.
> + *
> + * Note: there are no
Hi Guo,
> +/*
> + * set_bit - Atomically set a bit in memory
> + * @nr: the bit to set
> + * @addr: the address to start counting from
> + *
> + * This function is atomic and may not be reordered. See __set_bit()
> + * if you do not require the atomic guarantees.
> + *
> + * Note: there are no
On Mon, Sep 24, 2018 at 12:44:49PM +0200, Andrea Parri wrote:
> From the header comment for smp_mb__after_unlock_lock():
>
> "Place this after a lock-acquisition primitive to guarantee that
>an UNLOCK+LOCK pair acts as a full barrier. This guarantee applies
>if
On Mon, Sep 24, 2018 at 12:44:49PM +0200, Andrea Parri wrote:
> From the header comment for smp_mb__after_unlock_lock():
>
> "Place this after a lock-acquisition primitive to guarantee that
>an UNLOCK+LOCK pair acts as a full barrier. This guarantee applies
>if
RITE_ONCE(*y, 1);
r0 = READ_ONCE(*z);
spin_unlock(s);
}
P2(int *z, int *x)
{
int r0;
WRITE_ONCE(*z, 1);
smp_mb();
r0 = READ_ONCE(*x);
}
exists (0:r0=0 /\ 1:r0=0 /\ 2:r0=0)
Signed-off-by: Andrea Parri
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
RITE_ONCE(*y, 1);
r0 = READ_ONCE(*z);
spin_unlock(s);
}
P2(int *z, int *x)
{
int r0;
WRITE_ONCE(*z, 1);
smp_mb();
r0 = READ_ONCE(*x);
}
exists (0:r0=0 /\ 1:r0=0 /\ 2:r0=0)
Signed-off-by: Andrea Parri
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
y end up affecting the RISC-V implementation).
> The same argument may or may not apply to RMW-acquire/release;
> see also the second Con entry below.
>
> Linus feels that locks should be easy for people to use
> without worrying about memory consistency issues, si
y end up affecting the RISC-V implementation).
> The same argument may or may not apply to RMW-acquire/release;
> see also the second Con entry below.
>
> Linus feels that locks should be easy for people to use
> without worrying about memory consistency issues, si
later reads), but
> they recognize that this would incur a noticeable performance
> degradation on the POWER architecture. Linus also points out
> that people have made the mistake, in the past, of assuming
> that locking has stronger ordering properties than is
> curr
later reads), but
> they recognize that this would incur a noticeable performance
> degradation on the POWER architecture. Linus also points out
> that people have made the mistake, in the past, of assuming
> that locking has stronger ordering properties than is
> curr
On Tue, Sep 11, 2018 at 01:32:50PM +0100, Quentin Perret wrote:
> Hi Andrea,
>
> On Tuesday 11 Sep 2018 at 11:34:56 (+0200), Andrea Parri wrote:
> > FYI, the directory "tools/memory-model/" provides an "automated
> > memory-barriers.txt": in short, you e
On Tue, Sep 11, 2018 at 01:32:50PM +0100, Quentin Perret wrote:
> Hi Andrea,
>
> On Tuesday 11 Sep 2018 at 11:34:56 (+0200), Andrea Parri wrote:
> > FYI, the directory "tools/memory-model/" provides an "automated
> > memory-barriers.txt": in short, you e
Hi Quentin,
> > 1. use of a single memory barrier
> >
> >Since we are already em_pd_mutex protected, i.e. there cannot be a
> >concurrent writers, we can use one single memory barrier after the
> >loop, i.e.
> >
> > for_each_cpu(cpu, span)
> > WRITE_ONCE()
>
Hi Quentin,
> > 1. use of a single memory barrier
> >
> >Since we are already em_pd_mutex protected, i.e. there cannot be a
> >concurrent writers, we can use one single memory barrier after the
> >loop, i.e.
> >
> > for_each_cpu(cpu, span)
> > WRITE_ONCE()
>
> Will feels strongly (and Linus agrees) that the LKMM should not require
> ordinary acquire and release to be any stronger than RCpc.
>
> The issue that Andrea raised has to do with qspinlock, qrwlock, and
> mcs_spinlock, which are implemented using smp_cond_load_acquire()
> instead of
> Will feels strongly (and Linus agrees) that the LKMM should not require
> ordinary acquire and release to be any stronger than RCpc.
>
> The issue that Andrea raised has to do with qspinlock, qrwlock, and
> mcs_spinlock, which are implemented using smp_cond_load_acquire()
> instead of
On Wed, Sep 05, 2018 at 09:25:40PM -0400, Alan Stern wrote:
> On Mon, 3 Sep 2018, Andrea Parri wrote:
>
> > I take this opportunity to summarize my viewpoint on these matters:
> >
[1st approach/fix]
> > Someone would have to write the commit me
On Wed, Sep 05, 2018 at 09:25:40PM -0400, Alan Stern wrote:
> On Mon, 3 Sep 2018, Andrea Parri wrote:
>
> > I take this opportunity to summarize my viewpoint on these matters:
> >
[1st approach/fix]
> > Someone would have to write the commit me
> Do you have any concrete suggestions (i.e., some actual text) for
> improvements to the patch description? Earlier in your message you
> mentioned that Will's comment:
>
> LKMM offers stronger guarantees that can portably be relied upon
> in the codebase.
>
> Do you have any concrete suggestions (i.e., some actual text) for
> improvements to the patch description? Earlier in your message you
> mentioned that Will's comment:
>
> LKMM offers stronger guarantees that can portably be relied upon
> in the codebase.
>
On Wed, Sep 05, 2018 at 11:33:08PM +0900, Akira Yokosawa wrote:
> On 2018/09/05 09:21:51 +0200, Andrea Parri wrote:
> > On Tue, Sep 04, 2018 at 03:09:49PM -0400, Alan Stern wrote:
> >> On Tue, 4 Sep 2018, Andrea Parri wrote:
> >>> Heh, your confusion m
On Wed, Sep 05, 2018 at 11:33:08PM +0900, Akira Yokosawa wrote:
> On 2018/09/05 09:21:51 +0200, Andrea Parri wrote:
> > On Tue, Sep 04, 2018 at 03:09:49PM -0400, Alan Stern wrote:
> >> On Tue, 4 Sep 2018, Andrea Parri wrote:
> >>> Heh, your confusion m
On Tue, Sep 04, 2018 at 03:09:49PM -0400, Alan Stern wrote:
> On Tue, 4 Sep 2018, Andrea Parri wrote:
> > Heh, your confusion might be the reflection of mine... ;-) That was
> > indeed a long and not conclusive discussion (meaning there're pending
> > issues); and I
On Tue, Sep 04, 2018 at 03:09:49PM -0400, Alan Stern wrote:
> On Tue, 4 Sep 2018, Andrea Parri wrote:
> > Heh, your confusion might be the reflection of mine... ;-) That was
> > indeed a long and not conclusive discussion (meaning there're pending
> > issues); and I
> > In Cat speak,
> >
> > diff --git a/tools/memory-model/linux-kernel.cat
> > b/tools/memory-model/linux-kernel.cat
> > index 59b5cbe6b6240..fd9c0831adf0a 100644
> > --- a/tools/memory-model/linux-kernel.cat
> > +++ b/tools/memory-model/linux-kernel.cat
> > @@ -38,7 +38,7 @@ let strong-fence =
> > In Cat speak,
> >
> > diff --git a/tools/memory-model/linux-kernel.cat
> > b/tools/memory-model/linux-kernel.cat
> > index 59b5cbe6b6240..fd9c0831adf0a 100644
> > --- a/tools/memory-model/linux-kernel.cat
> > +++ b/tools/memory-model/linux-kernel.cat
> > @@ -38,7 +38,7 @@ let strong-fence =
On Mon, Sep 03, 2018 at 01:52:07PM -0400, Alan Stern wrote:
> On Mon, 3 Sep 2018, Andrea Parri wrote:
>
> > In Cat speak,
> >
> > diff --git a/tools/memory-model/linux-kernel.cat
> > b/tools/memory-model/linux-kernel.cat
> > index 59b5cbe6b6240..fd9c0831adf0a
On Mon, Sep 03, 2018 at 01:52:07PM -0400, Alan Stern wrote:
> On Mon, 3 Sep 2018, Andrea Parri wrote:
>
> > In Cat speak,
> >
> > diff --git a/tools/memory-model/linux-kernel.cat
> > b/tools/memory-model/linux-kernel.cat
> > index 59b5cbe6b6240..fd9c0831adf0a
On Fri, Aug 31, 2018 at 08:28:46PM +0200, Andrea Parri wrote:
> > > Yes, it's true that implementing locks with atomic_cmpxchg_acquire
> > > should be correct on all existing architectures. And Paul has invited
> > > a patch to modify the LKMM accordingly. If
On Fri, Aug 31, 2018 at 08:28:46PM +0200, Andrea Parri wrote:
> > > Yes, it's true that implementing locks with atomic_cmpxchg_acquire
> > > should be correct on all existing architectures. And Paul has invited
> > > a patch to modify the LKMM accordingly. If
> > Yes, it's true that implementing locks with atomic_cmpxchg_acquire
> > should be correct on all existing architectures. And Paul has invited
> > a patch to modify the LKMM accordingly. If you feel that such a change
> > would be a useful enhancement to the LKMM's applicability, please
> > Yes, it's true that implementing locks with atomic_cmpxchg_acquire
> > should be correct on all existing architectures. And Paul has invited
> > a patch to modify the LKMM accordingly. If you feel that such a change
> > would be a useful enhancement to the LKMM's applicability, please
On Fri, Aug 31, 2018 at 10:52:54AM -0400, Alan Stern wrote:
> On Fri, 31 Aug 2018, Andrea Parri wrote:
>
> > On Thu, Aug 30, 2018 at 05:31:32PM -0400, Alan Stern wrote:
> > > On Thu, 30 Aug 2018, Andrea Parri wrote:
> > >
> > > > > All the architect
On Fri, Aug 31, 2018 at 10:52:54AM -0400, Alan Stern wrote:
> On Fri, 31 Aug 2018, Andrea Parri wrote:
>
> > On Thu, Aug 30, 2018 at 05:31:32PM -0400, Alan Stern wrote:
> > > On Thu, 30 Aug 2018, Andrea Parri wrote:
> > >
> > > > > All the architect
ot;)
> >
> > but I can only vaguely remember those dependencies issues now :/ ...;
> > maybe we can now solve these issues? or should we change herd7 to re-
> > turn a warning? (Notice that this primitive is currently not exported
> > to the linux-kernel.def file.)
>
> Cool! It would be good to add this to the .def file once the underlying
> herd7 machinery is ready. And then I would update the documentation
> accordingly. Or happily accept a patch updating the documentation,
> as the case might be. ;-)
Fair enough, ;-) Please feel free to add:
Reviewed-by: Andrea Parri
Andrea
ot;)
> >
> > but I can only vaguely remember those dependencies issues now :/ ...;
> > maybe we can now solve these issues? or should we change herd7 to re-
> > turn a warning? (Notice that this primitive is currently not exported
> > to the linux-kernel.def file.)
>
> Cool! It would be good to add this to the .def file once the underlying
> herd7 machinery is ready. And then I would update the documentation
> accordingly. Or happily accept a patch updating the documentation,
> as the case might be. ;-)
Fair enough, ;-) Please feel free to add:
Reviewed-by: Andrea Parri
Andrea
On Thu, Aug 30, 2018 at 05:31:32PM -0400, Alan Stern wrote:
> On Thu, 30 Aug 2018, Andrea Parri wrote:
>
> > > All the architectures supported by the Linux kernel (including RISC-V)
> > > do provide this ordering for locks, albeit for varying reasons.
> > > There
On Thu, Aug 30, 2018 at 05:31:32PM -0400, Alan Stern wrote:
> On Thu, 30 Aug 2018, Andrea Parri wrote:
>
> > > All the architectures supported by the Linux kernel (including RISC-V)
> > > do provide this ordering for locks, albeit for varying reasons.
> > > There
On Wed, Aug 29, 2018 at 02:10:47PM -0700, Paul E. McKenney wrote:
> From: Alan Stern
>
> More than one kernel developer has expressed the opinion that the LKMM
> should enforce ordering of writes by locking. In other words, given
> the following code:
>
> WRITE_ONCE(x, 1);
>
On Wed, Aug 29, 2018 at 02:10:47PM -0700, Paul E. McKenney wrote:
> From: Alan Stern
>
> More than one kernel developer has expressed the opinion that the LKMM
> should enforce ordering of writes by locking. In other words, given
> the following code:
>
> WRITE_ONCE(x, 1);
>
On Wed, Aug 29, 2018 at 02:10:49PM -0700, Paul E. McKenney wrote:
> This commit adds more detail about compiler optimizations and
> not-yet-modeled Linux-kernel APIs.
>
> Signed-off-by: Paul E. McKenney
> ---
> tools/memory-model/README | 39 +++
> 1 file
On Wed, Aug 29, 2018 at 02:10:49PM -0700, Paul E. McKenney wrote:
> This commit adds more detail about compiler optimizations and
> not-yet-modeled Linux-kernel APIs.
>
> Signed-off-by: Paul E. McKenney
> ---
> tools/memory-model/README | 39 +++
> 1 file
> > That said, I don't understand the powerpc memory ordering. I thought
> > the rules were "isync on lock, lwsync on unlock".
> >
> > That's what the AIX docs imply, at least.
> >
> > In particular, I find:
> >
> > "isync is not a memory barrier instruction, but the
> >
> > That said, I don't understand the powerpc memory ordering. I thought
> > the rules were "isync on lock, lwsync on unlock".
> >
> > That's what the AIX docs imply, at least.
> >
> > In particular, I find:
> >
> > "isync is not a memory barrier instruction, but the
> >
Commit-ID: 71b7ff5ebc9b1d5aa95eb48d6388234f1304fd19
Gitweb: https://git.kernel.org/tip/71b7ff5ebc9b1d5aa95eb48d6388234f1304fd19
Author: Andrea Parri
AuthorDate: Mon, 16 Jul 2018 11:06:05 -0700
Committer: Ingo Molnar
CommitDate: Tue, 17 Jul 2018 09:30:36 +0200
tools/memory-model
Commit-ID: 71b7ff5ebc9b1d5aa95eb48d6388234f1304fd19
Gitweb: https://git.kernel.org/tip/71b7ff5ebc9b1d5aa95eb48d6388234f1304fd19
Author: Andrea Parri
AuthorDate: Mon, 16 Jul 2018 11:06:05 -0700
Committer: Ingo Molnar
CommitDate: Tue, 17 Jul 2018 09:30:36 +0200
tools/memory-model
Commit-ID: 7696f9910a9a40b8a952f57d3428515fabd2d889
Gitweb: https://git.kernel.org/tip/7696f9910a9a40b8a952f57d3428515fabd2d889
Author: Andrea Parri
AuthorDate: Mon, 16 Jul 2018 11:06:03 -0700
Committer: Ingo Molnar
CommitDate: Tue, 17 Jul 2018 09:30:34 +0200
sched/Documentation
Commit-ID: 7696f9910a9a40b8a952f57d3428515fabd2d889
Gitweb: https://git.kernel.org/tip/7696f9910a9a40b8a952f57d3428515fabd2d889
Author: Andrea Parri
AuthorDate: Mon, 16 Jul 2018 11:06:03 -0700
Committer: Ingo Molnar
CommitDate: Tue, 17 Jul 2018 09:30:34 +0200
sched/Documentation
Commit-ID: 3d85b2703783636366560c94842affd8608ec9d1
Gitweb: https://git.kernel.org/tip/3d85b2703783636366560c94842affd8608ec9d1
Author: Andrea Parri
AuthorDate: Mon, 16 Jul 2018 11:06:02 -0700
Committer: Ingo Molnar
CommitDate: Tue, 17 Jul 2018 09:30:33 +0200
locking/spinlock, sched
Commit-ID: 3d85b2703783636366560c94842affd8608ec9d1
Gitweb: https://git.kernel.org/tip/3d85b2703783636366560c94842affd8608ec9d1
Author: Andrea Parri
AuthorDate: Mon, 16 Jul 2018 11:06:02 -0700
Committer: Ingo Molnar
CommitDate: Tue, 17 Jul 2018 09:30:33 +0200
locking/spinlock, sched
Commit-ID: 76e079fefc8f62bd9b2cd2950814d1ee806e31a5
Gitweb: https://git.kernel.org/tip/76e079fefc8f62bd9b2cd2950814d1ee806e31a5
Author: Andrea Parri
AuthorDate: Mon, 16 Jul 2018 11:06:01 -0700
Committer: Ingo Molnar
CommitDate: Tue, 17 Jul 2018 09:30:33 +0200
sched/core: Use smp_mb
Commit-ID: 76e079fefc8f62bd9b2cd2950814d1ee806e31a5
Gitweb: https://git.kernel.org/tip/76e079fefc8f62bd9b2cd2950814d1ee806e31a5
Author: Andrea Parri
AuthorDate: Mon, 16 Jul 2018 11:06:01 -0700
Committer: Ingo Molnar
CommitDate: Tue, 17 Jul 2018 09:30:33 +0200
sched/core: Use smp_mb
On Fri, Jul 13, 2018 at 06:42:39PM +0200, Peter Zijlstra wrote:
>
> Hi Michael,
>
> On Fri, Jul 13, 2018 at 11:15:26PM +1000, Michael Ellerman wrote:
> > I reran some numbers today with some slightly updated tests.
> >
> > It varies quite a bit across machines and CPU revisions.
> >
> > On one
On Fri, Jul 13, 2018 at 06:42:39PM +0200, Peter Zijlstra wrote:
>
> Hi Michael,
>
> On Fri, Jul 13, 2018 at 11:15:26PM +1000, Michael Ellerman wrote:
> > I reran some numbers today with some slightly updated tests.
> >
> > It varies quite a bit across machines and CPU revisions.
> >
> > On one
On Fri, Jul 13, 2018 at 10:16:48AM -0700, Linus Torvalds wrote:
> On Fri, Jul 13, 2018 at 2:34 AM Will Deacon wrote:
> >
> > And, since we're stating preferences, I'll reiterate my preference towards:
> >
> > * RCsc unlock/lock
> > * RCpc release/acquire
>
> Yes, I think this
On Fri, Jul 13, 2018 at 10:16:48AM -0700, Linus Torvalds wrote:
> On Fri, Jul 13, 2018 at 2:34 AM Will Deacon wrote:
> >
> > And, since we're stating preferences, I'll reiterate my preference towards:
> >
> > * RCsc unlock/lock
> > * RCpc release/acquire
>
> Yes, I think this
On Thu, Jul 12, 2018 at 07:05:39PM -0700, Daniel Lustig wrote:
> On 7/12/2018 11:10 AM, Linus Torvalds wrote:
> > On Thu, Jul 12, 2018 at 11:05 AM Peter Zijlstra
> > wrote:
> >>
> >> The locking pattern is fairly simple and shows where RCpc comes apart
> >> from expectation real nice.
> >
> >
On Thu, Jul 12, 2018 at 07:05:39PM -0700, Daniel Lustig wrote:
> On 7/12/2018 11:10 AM, Linus Torvalds wrote:
> > On Thu, Jul 12, 2018 at 11:05 AM Peter Zijlstra
> > wrote:
> >>
> >> The locking pattern is fairly simple and shows where RCpc comes apart
> >> from expectation real nice.
> >
> >
On Thu, Jul 12, 2018 at 11:13:48PM +0200, Andrea Parri wrote:
> On Thu, Jul 12, 2018 at 04:43:46PM -0400, Alan Stern wrote:
> > On Thu, 12 Jul 2018, Andrea Parri wrote:
> >
> > > > It seems reasonable to ask people to learn that locks have stronger
> > > >
On Thu, Jul 12, 2018 at 11:13:48PM +0200, Andrea Parri wrote:
> On Thu, Jul 12, 2018 at 04:43:46PM -0400, Alan Stern wrote:
> > On Thu, 12 Jul 2018, Andrea Parri wrote:
> >
> > > > It seems reasonable to ask people to learn that locks have stronger
> > > >
On Thu, Jul 12, 2018 at 04:43:46PM -0400, Alan Stern wrote:
> On Thu, 12 Jul 2018, Andrea Parri wrote:
>
> > > It seems reasonable to ask people to learn that locks have stronger
> > > ordering guarantees than RMW atomics do. Maybe not the greatest
> > > situat
On Thu, Jul 12, 2018 at 04:43:46PM -0400, Alan Stern wrote:
> On Thu, 12 Jul 2018, Andrea Parri wrote:
>
> > > It seems reasonable to ask people to learn that locks have stronger
> > > ordering guarantees than RMW atomics do. Maybe not the greatest
> > > situat
On Thu, Jul 12, 2018 at 09:52:42PM +0200, Andrea Parri wrote:
> On Thu, Jul 12, 2018 at 11:10:58AM -0700, Linus Torvalds wrote:
> > On Thu, Jul 12, 2018 at 11:05 AM Peter Zijlstra
> > wrote:
> > >
> > > The locking pattern is fairly simple and shows where RCpc c
On Thu, Jul 12, 2018 at 09:52:42PM +0200, Andrea Parri wrote:
> On Thu, Jul 12, 2018 at 11:10:58AM -0700, Linus Torvalds wrote:
> > On Thu, Jul 12, 2018 at 11:05 AM Peter Zijlstra
> > wrote:
> > >
> > > The locking pattern is fairly simple and shows where RCpc c
On Thu, Jul 12, 2018 at 11:10:58AM -0700, Linus Torvalds wrote:
> On Thu, Jul 12, 2018 at 11:05 AM Peter Zijlstra wrote:
> >
> > The locking pattern is fairly simple and shows where RCpc comes apart
> > from expectation real nice.
>
> So who does RCpc right now for the unlock-lock sequence?
On Thu, Jul 12, 2018 at 11:10:58AM -0700, Linus Torvalds wrote:
> On Thu, Jul 12, 2018 at 11:05 AM Peter Zijlstra wrote:
> >
> > The locking pattern is fairly simple and shows where RCpc comes apart
> > from expectation real nice.
>
> So who does RCpc right now for the unlock-lock sequence?
> It seems reasonable to ask people to learn that locks have stronger
> ordering guarantees than RMW atomics do. Maybe not the greatest
> situation in the world, but one I think we could live with.
Yeah, this was one of my main objections.
> > Hence my proposal to strenghten rmw-acquire,
> It seems reasonable to ask people to learn that locks have stronger
> ordering guarantees than RMW atomics do. Maybe not the greatest
> situation in the world, but one I think we could live with.
Yeah, this was one of my main objections.
> > Hence my proposal to strenghten rmw-acquire,
> Anyway, back to the problem of being able to use the memory model to
> describe locks. This is I think a useful property.
>
> My earlier reasoning was that:
>
> - smp_store_release() + smp_load_acquire() := RCpc
>
> - we use smp_store_release() as unlock()
>
> Therefore, if we want
> Anyway, back to the problem of being able to use the memory model to
> describe locks. This is I think a useful property.
>
> My earlier reasoning was that:
>
> - smp_store_release() + smp_load_acquire() := RCpc
>
> - we use smp_store_release() as unlock()
>
> Therefore, if we want
On Thu, Jul 12, 2018 at 01:52:49PM +0200, Andrea Parri wrote:
> On Thu, Jul 12, 2018 at 09:40:40AM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 11, 2018 at 02:34:21PM +0200, Andrea Parri wrote:
> > > Simplicity is the eye of the beholder. From my POV (LKMM maintainer), the
>
On Thu, Jul 12, 2018 at 01:52:49PM +0200, Andrea Parri wrote:
> On Thu, Jul 12, 2018 at 09:40:40AM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 11, 2018 at 02:34:21PM +0200, Andrea Parri wrote:
> > > Simplicity is the eye of the beholder. From my POV (LKMM maintainer), the
>
On Thu, Jul 12, 2018 at 09:40:40AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 11, 2018 at 02:34:21PM +0200, Andrea Parri wrote:
> > Simplicity is the eye of the beholder. From my POV (LKMM maintainer), the
> > simplest solution would be to get rid of rfi-rel-acq and unlock-rf-lock
On Thu, Jul 12, 2018 at 09:40:40AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 11, 2018 at 02:34:21PM +0200, Andrea Parri wrote:
> > Simplicity is the eye of the beholder. From my POV (LKMM maintainer), the
> > simplest solution would be to get rid of rfi-rel-acq and unlock-rf-lock
> All the discussion here[1] for example is about having ordering and
> doing an smp_cond_load_acquire() on a variable which is sometimes
> protected by a CPU's rq->lock and sometimes not? Isn't that one of the
> key use cases for this whole discussion?
Not a "pure" one:
> All the discussion here[1] for example is about having ordering and
> doing an smp_cond_load_acquire() on a variable which is sometimes
> protected by a CPU's rq->lock and sometimes not? Isn't that one of the
> key use cases for this whole discussion?
Not a "pure" one:
> It might be simple to model, but I worry this weakens our locking
> implementations to a point where they will not be understood by the average
> kernel developer. As I've said before, I would prefer "full" RCsc locking,
> but that's not the case with architectures we currently support today, so
> It might be simple to model, but I worry this weakens our locking
> implementations to a point where they will not be understood by the average
> kernel developer. As I've said before, I would prefer "full" RCsc locking,
> but that's not the case with architectures we currently support today, so
On Wed, Jul 11, 2018 at 08:42:11AM -0700, Paul E. McKenney wrote:
> On Wed, Jul 11, 2018 at 10:43:45AM +0100, Will Deacon wrote:
> > Hi Alan,
> >
> > On Tue, Jul 10, 2018 at 02:18:13PM -0400, Alan Stern wrote:
> > > More than one kernel developer has expressed the opinion that the LKMM
> > >
On Wed, Jul 11, 2018 at 08:42:11AM -0700, Paul E. McKenney wrote:
> On Wed, Jul 11, 2018 at 10:43:45AM +0100, Will Deacon wrote:
> > Hi Alan,
> >
> > On Tue, Jul 10, 2018 at 02:18:13PM -0400, Alan Stern wrote:
> > > More than one kernel developer has expressed the opinion that the LKMM
> > >
On Wed, Jul 11, 2018 at 02:34:21PM +0200, Andrea Parri wrote:
> On Wed, Jul 11, 2018 at 10:43:11AM +0100, Will Deacon wrote:
> > On Tue, Jul 10, 2018 at 11:38:21AM +0200, Andrea Parri wrote:
> > > On Mon, Jul 09, 2018 at 04:01:57PM -0400, Alan Stern wrote:
> > > >
On Wed, Jul 11, 2018 at 02:34:21PM +0200, Andrea Parri wrote:
> On Wed, Jul 11, 2018 at 10:43:11AM +0100, Will Deacon wrote:
> > On Tue, Jul 10, 2018 at 11:38:21AM +0200, Andrea Parri wrote:
> > > On Mon, Jul 09, 2018 at 04:01:57PM -0400, Alan Stern wrote:
> > > >
On Wed, Jul 11, 2018 at 10:43:11AM +0100, Will Deacon wrote:
> On Tue, Jul 10, 2018 at 11:38:21AM +0200, Andrea Parri wrote:
> > On Mon, Jul 09, 2018 at 04:01:57PM -0400, Alan Stern wrote:
> > > More than one kernel developer has expressed the opinion that the LKMM
> > &
On Wed, Jul 11, 2018 at 10:43:11AM +0100, Will Deacon wrote:
> On Tue, Jul 10, 2018 at 11:38:21AM +0200, Andrea Parri wrote:
> > On Mon, Jul 09, 2018 at 04:01:57PM -0400, Alan Stern wrote:
> > > More than one kernel developer has expressed the opinion that the LKMM
> > &
On Tue, Jul 10, 2018 at 01:17:50PM -0400, Alan Stern wrote:
> On Tue, 10 Jul 2018, Daniel Lustig wrote:
>
> > > --- usb-4.x.orig/tools/memory-model/linux-kernel.cat
> > > +++ usb-4.x/tools/memory-model/linux-kernel.cat
> > > @@ -38,7 +38,7 @@ let strong-fence = mb | gp
> > > (* Release Acquire
On Tue, Jul 10, 2018 at 01:17:50PM -0400, Alan Stern wrote:
> On Tue, 10 Jul 2018, Daniel Lustig wrote:
>
> > > --- usb-4.x.orig/tools/memory-model/linux-kernel.cat
> > > +++ usb-4.x/tools/memory-model/linux-kernel.cat
> > > @@ -38,7 +38,7 @@ let strong-fence = mb | gp
> > > (* Release Acquire
On Tue, Jul 10, 2018 at 11:34:45AM -0400, Alan Stern wrote:
> On Tue, 10 Jul 2018, Andrea Parri wrote:
>
> > > > ACQUIRE operations include LOCK operations and both smp_load_acquire()
> > > > and smp_cond_acquire() operations. [BTW, the latter was replaced by
&
On Tue, Jul 10, 2018 at 11:34:45AM -0400, Alan Stern wrote:
> On Tue, 10 Jul 2018, Andrea Parri wrote:
>
> > > > ACQUIRE operations include LOCK operations and both smp_load_acquire()
> > > > and smp_cond_acquire() operations. [BTW, the latter was replaced by
&
401 - 500 of 1000 matches
Mail list logo
