From: Peter Zijlstra
> Sent: 11 July 2018 12:10
..
> Adding SYNC to WRITE_ONCE()/atomic* will hurt performance lots and will
> ultimately not guarantee anything more; and as Will said, keep you
> chasing dragons where people forgot to use WRITE_ONCE() where they maybe
> should've.
Also WRITE_ONCE(
On Wed, Jul 11, 2018 at 11:21:06AM +0100, Will Deacon wrote:
> On Wed, Jul 11, 2018 at 06:05:51PM +0800, Jiaxun Yang wrote:
> > On 2018-7-10 Tue at 20:17:27，Peter Zijlstra Wrote：
> > > Still, even with the rules above, the best work-around is still the very
> > > same cpu_relax() hack.
> >
> > As
On Wed, Jul 11, 2018 at 10:04:52AM +, David Laight wrote:
> I also suspect that 'write starvation' is also common - after all the
> purpose of the store buffer is to do reads in preference to writes in
> order to reduce the cpu stalls waiting for the memory bus (probably
> the cpu to cache inte
On 2018-7-10 Tue at 20:17:27，Peter Zijlstra Wrote：
Hi Peter
Since Huacai unable to send email via client, I'm going to reply for him
> Sure.. we all got that far. And no, this isn't the _real_ problem. This
> is a manifestation of the problem.
>
> The problem is that your SFB is broken (per th
On Wed, Jul 11, 2018 at 06:05:51PM +0800, Jiaxun Yang wrote:
> On 2018-7-10 Tue at 20:17:27，Peter Zijlstra Wrote：
>
> Hi Peter
> Since Huacai unable to send email via client, I'm going to reply for him
>
> > Sure.. we all got that far. And no, this isn't the _real_ problem. This
> > is a manife
From: Paul Burton
> Sent: 10 July 2018 18:11
...
> I'm not sure which is the intent (I can ask if someone's interested),
> but you could either:
>
> 1) Consider the store buffer a cache, in which case loads need to
> check all store buffers from all CPUs because of the "all caches"
> p
Hi Huacai,
On Tue, Jul 10, 2018 at 07:45:22PM +0800, 陈华才 wrote:
> I don't think this is a hardware bug, in design, SFB will flushed to L1
> cache in three cases:
> 1, data in SFB is full (be a complete cache line);
> 2, there is a subsequent read access in the same cache line;
> 3, a 'sync' instru
Hello,
On Tue, Jul 10, 2018 at 02:17:27PM +0200, Peter Zijlstra wrote:
> > 1, CPU0 set the lock to 0, then do something;
> > 2, While CPU0 is doing something, CPU1 set the flag to 1 with
> > WRITE_ONCE(), and then wait the lock become to 1 with a READ_ONCE()
> > loop;
> > 3, After CPU0
On Tue, Jul 10, 2018 at 02:17:27PM +0200, Peter Zijlstra wrote:
>
> Please!! Learn to use email.
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> Also, wrap no
Please!! Learn to use email.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Also, wrap non-quoted lines to 78 characters.
On Tue, Jul 10, 2018 at 07:45:22PM +0800, 陈华才 w
t;Paul Burton"; "Ralf Baechle";
"James Hogan"; "linux-mips";
"Fuxin Zhang"; "wuzhangjin";
"stable"; "Alan Stern";
"Andrea Parri"; "Will
Deacon"; "Boqun Feng"; "Nicholas
Piggin"; "David H
On Tue, Jul 10, 2018 at 11:36:37AM +0200, Peter Zijlstra wrote:
> So now explain why the cpu_relax() hack that arm did doesn't work for
> you?
So below is the patch I think you want; if not explain in detail how
this is wrong.
diff --git a/arch/mips/include/asm/processor.h
b/arch/mips/include/a
On Tue, Jul 10, 2018 at 12:26:34PM +0800, Huacai Chen wrote:
> Hi, Paul and Peter,
>
> I think we find the real root cause, READ_ONCE() doesn't need any
> barriers, the problematic code is queued_spin_lock_slowpath() in
> kernel/locking/qspinlock.c:
>
> if (old & _Q_TAIL_MASK) {
>
Hi, Paul and Peter,
I think we find the real root cause, READ_ONCE() doesn't need any
barriers, the problematic code is queued_spin_lock_slowpath() in
kernel/locking/qspinlock.c:
if (old & _Q_TAIL_MASK) {
prev = decode_tail(old);
/* Link @node into the wai
Hi Huacai,
On Mon, Jul 09, 2018 at 10:26:38AM +0800, Huacai Chen wrote:
> After commit 7f56b58a92aaf2c ("locking/mcs: Use smp_cond_load_acquire()
> in MCS spin loop") Loongson-3 fails to boot. This is because Loongson-3
> has SFB (Store Fill Buffer) and the weak-ordering may cause READ_ONCE()
> to
15 matches
Mail list logo
