From: David Laight <David.Laight@ACULAB.COM>
To: "'Paul Burton'" <paul.burton@mips.com>,
"Peter Zijlstra" <peterz@infradead.org>, 陈华才 <chenhc@lemote.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
James Hogan <jhogan@kernel.org>,
linux-mips <linux-mips@linux-mips.org>,
Fuxin Zhang <zhangfx@lemote.com>,
wuzhangjin <wuzhangjin@gmail.com>,
stable <stable@vger.kernel.org>,
"Alan Stern" <stern@rowland.harvard.edu>,
Andrea Parri <andrea.parri@amarulasolutions.com>,
Will Deacon <will.deacon@arm.com>,
Boqun Feng <boqun.feng@gmail.com>,
Nicholas Piggin <npiggin@gmail.com>,
David Howells <dhowells@redhat.com>,
Jade Alglave <j.alglave@ucl.ac.uk>,
Luc Maranget <luc.maranget@inria.fr>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Akira Yokosawa <akiyks@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH V2] MIPS: implement smp_cond_load_acquire() for Loongson-3
Date: Wed, 11 Jul 2018 10:04:52 +0000 [thread overview]
Message-ID: <1a072b07261b46d88938f0f709f54d42@AcuMS.aculab.com> (raw)
In-Reply-To: <20180710171040.f3gyyh524xlsqv4j@pburton-laptop>
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"
> part of the first quoted sentence.
>
> or
>
> 2) Decide store buffers aren't covered by the MIPS architecture
> documentation at all in which case the only sane thing to do would
> be to make it transparent to software (and here Loongson's isn't)
...
Store buffers are common and are never transparent to multi-threaded code.
They are largely why you need locks.
At least on (early) sparc systems they were between the execution unit
and the data cache.
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 interface).
I think your example is just:
*(volatile int *)xxx = 1;
while (!*(volatile int *)yyy) continue;
running on two cpu with xxx and yyy swapped?
You need a stronger bus cycle in there somewhere.
David
next prev parent reply other threads:[~2018-07-11 10:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1531103198-16764-1-git-send-email-chenhc@lemote.com>
2018-07-09 16:49 ` Paul Burton
2018-07-10 4:26 ` Huacai Chen
2018-07-10 9:36 ` Peter Zijlstra
2018-07-10 10:54 ` Peter Zijlstra
2018-07-10 11:45 ` 陈华才
2018-07-10 12:17 ` Peter Zijlstra
2018-07-10 16:14 ` Paul E. McKenney
2018-07-10 17:10 ` Paul Burton
2018-07-11 10:04 ` David Laight [this message]
2018-07-11 10:55 ` Peter Zijlstra
2018-07-11 10:05 ` Jiaxun Yang
2018-07-11 10:21 ` Will Deacon
2018-07-11 11:09 ` Peter Zijlstra
2018-07-11 11:46 ` David Laight
2018-07-11 9:43 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1a072b07261b46d88938f0f709f54d42@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=akiyks@gmail.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=boqun.feng@gmail.com \
--cc=chenhc@lemote.com \
--cc=dhowells@redhat.com \
--cc=j.alglave@ucl.ac.uk \
--cc=jhogan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=paul.burton@mips.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=ralf@linux-mips.org \
--cc=stable@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=will.deacon@arm.com \
--cc=wuzhangjin@gmail.com \
--cc=zhangfx@lemote.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®