search for: lkmm

'smp_read_barrier_depends()' has gone the way of mmiowb() and so many esoteric memory barriers before it. Drop the two mentions of this deceased barrier from the LKMM informal explanation document. Signed-off-by: Will Deacon <will at kernel.org> --- .../Documentation/explanation.txt | 26 +++++++++---------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Do...

Hi all, Although [smp_]read_barrier_depends() became part of READ_ONCE() in commit 76ebbe78f739 ("locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()"), it still limps on in the Linux memory model with the sinister hope of attracting innocent new users so that it becomes impossible to remove altogether. Let's strike before it's too late: there's only

...UIRE N, STORE *B, STORE *A, RELEASE M > " > > But it doesn't explain what happen when > > *A = a > RELEASE M > ACQUIRE M > *B = b; > > And tools/memory-model/Documentation said > > " > First, when a lock-acquire reads from a lock-release, the LKMM > requires that every instruction po-before the lock-release must > execute before any instruction po-after the lock-acquire. > " > > Is this a hint that I was correct? I don't think it's correct since by this logic memory barriers can be nops on x86. > > > &...

...t; *A = a; RELEASE M ACQUIRE N *B = b; could occur as: ACQUIRE N, STORE *B, STORE *A, RELEASE M " But it doesn't explain what happen when *A = a RELEASE M ACQUIRE M *B = b; And tools/memory-model/Documentation said " First, when a lock-acquire reads from a lock-release, the LKMM requires that every instruction po-before the lock-release must execute before any instruction po-after the lock-acquire. " Is this a hint that I was correct? > > > And if we also had the reverse rule we'd end up with a full barrier, > won't we? > > Cc Paul in case...

On Wed, Jul 31, 2019 at 04:46:53AM -0400, Jason Wang wrote: > We used to use RCU to synchronize MMU notifier with worker. This leads > calling synchronize_rcu() in invalidate_range_start(). But on a busy > system, there would be many factors that may slow down the > synchronize_rcu() which makes it unsuitable to be called in MMU > notifier. > > A solution is SRCU but its

On Wed, Jul 31, 2019 at 04:46:53AM -0400, Jason Wang wrote: > We used to use RCU to synchronize MMU notifier with worker. This leads > calling synchronize_rcu() in invalidate_range_start(). But on a busy > system, there would be many factors that may slow down the > synchronize_rcu() which makes it unsuitable to be called in MMU > notifier. > > A solution is SRCU but its

Hi all, This is version three of the patches I previously posted here: v1: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ v2: https://lore.kernel.org/r/20200630173734.14057-1-will at kernel.org Changes since v2 include: * Actually add the barrier in READ_ONCE() for Alpha! * Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than the other

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The

Hi everyone, This is the long-awaited version two of the patches I previously posted in November last year: https://lore.kernel.org/lkml/20191108170120.22331-1-will at kernel.org/ I ended up parking the series while the READ_ONCE() implementation was being overhauled, but with that merged during the recent merge window and LTO patches being posted again [1], it was time for a refresh. The