On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote:
On Fri, 15 Jan 2016, Leonid Yegoshin wrote:
So you need to build a different kernel for some types of MIPS systems?
Or do you do boot-time rewriting, like a number of other arches do?
I don't know. I would like to have responses. Ralf
On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote:
On Fri, 15 Jan 2016, Leonid Yegoshin wrote:
So you need to build a different kernel for some types of MIPS systems?
Or do you do boot-time rewriting, like a number of other arches do?
I don't know. I would like to have responses. Ralf
On 01/15/2016 01:57 AM, Will Deacon wrote:
Paul,
I think you figured this out while I was sleeping, but just to confirm:
1. The MIPS64 ISA doc [1] talks about SYNC in a way that applies only
to memory accesses appearing in *program-order* before the SYNC
2. We need WRC+sync+addr to w
On 01/14/2016 04:47 PM, Paul E. McKenney wrote:
On Thu, Jan 14, 2016 at 03:33:40PM -0800, Leonid Yegoshin wrote:
Don't be fooled here by words "ordered" and "completed" - it is HW
design items and actually written poorly.
Just assume that SYNC_MB is absolutely the sam
On 01/14/2016 02:55 PM, Paul E. McKenney wrote:
OK, so it looks like Will was asking not about WRC+addr+addr, but instead
about WRC+sync+addr.
(He actually asked twice about this and that too but skip this)
I am guessing that the manual's "Older instructions which must be globally
performed wh
On 01/14/2016 02:24 PM, Paul E. McKenney wrote:
Actually, the Linux kernel doesn't have an acquire barrier, just an
smp_load_acquire(). Or did someone sneak one in while I wasn't looking?
That was an exactly starting point for this discussion. This patch just
pulls out from MIPS files smp_load_a
On 01/14/2016 01:34 PM, Paul E. McKenney wrote:
On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote:
On 01/14/2016 12:15 PM, Peter Zijlstra wrote:
On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote:
An the only point - please use an appropriate SYNC_* barriers instead
On 01/14/2016 01:29 PM, Paul E. McKenney wrote:
On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
The WRC+addr+addr is OK because data dependencies are not required to be
transitive, in other words, they are not required to flow from one CPU to
another without the help of an explicit memory bar
On 01/14/2016 12:48 PM, Paul E. McKenney wrote:
So SYNC_RMB is intended to implement smp_rmb(), correct?
Yes.
You could use SYNC_ACQUIRE() to implement read_barrier_depends() and
smp_read_barrier_depends(), but SYNC_RMB probably does not suffice.
If smp_read_barrier_depends() is used to sep
I need some time to understand your test examples. However,
On 01/14/2016 12:34 PM, Paul E. McKenney wrote:
The WRC+addr+addr is OK because data dependencies are not required to be
transitive, in other words, they are not required to flow from one CPU to
another without the help of an explicit
On 01/14/2016 12:15 PM, Peter Zijlstra wrote:
On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote:
An the only point - please use an appropriate SYNC_* barriers instead of
heavy bold hammer. That stuff was design explicitly to support the
requirements of Documentation/memory
On 01/14/2016 04:04 AM, Will Deacon wrote:
Consequently, it's important that the architecture back-ends implement
these portable primitives (e.g. smp_mb()) in a way that satisfies the
kernel memory model so that core code doesn't need to worry about the
underlying architecture for synchronisati
On 01/14/2016 08:16 AM, Paul E. McKenney wrote:
On Thu, Jan 14, 2016 at 12:04:45PM +, Will Deacon wrote:
On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote:
On 01/13/2016 12:48 PM, Peter Zijlstra wrote:
On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:
I ask
On 01/14/2016 04:14 AM, Will Deacon wrote:
On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote:
Moreover, there are voices against guarantee that it will be in future
and that voices point me to Documentation/memory-barriers.txt section "DATA
DEPENDENCY BARRIERS"
On 01/13/2016 02:45 AM, Will Deacon wrote:
I don't think the address dependency is enough on its own. By that
reasoning, the following variant (WRC+addr+addr) would work too:
P0:
Wx = 1
P1:
Rx == 1
Wy = 1
P2:
Ry == 1
Rx = 0
So are you saying that this is also forbidden?
Imagine that P0
On 01/13/2016 12:48 PM, Peter Zijlstra wrote:
On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:
I ask HW team about it but I have a question - has it any relationship with
replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)?
Of course. If you cannot explain the semantics
On 01/13/2016 02:45 AM, Will Deacon wrote:
On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote:
I don't think the address dependency is enough on its own. By that
reasoning, the following variant (WRC+addr+addr) would work too:
P0:
Wx = 1
P1:
Rx == 1
Wy = 1
P2:
Ry ==
On 01/12/2016 01:40 PM, Peter Zijlstra wrote:
It is selectable only for MIPS R2 but not MIPS R6. The reason is - most of
MIPS R2 CPUs have short pipeline and that SYNC is just waste of CPU
resource, especially taking into account that "lightweight syncs" are
converted to a heavy "SYNC 0" in man
(I try to answer on multiple mails in one)
First of all, it seems like some generic notes should be given here:
1. Generic MIPS "SYNC" (aka "SYNC 0") instruction is a very heavy in
some CPUs. On that CPUs it basically kills pipelines in each CPU, can do
a special memory/IO bus transaction (sim
On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote:
On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends,
smp_read_barrier_depends, smp_store_release and smp_load_acquire match
the asm-generic variants exactly. Drop the local definitions and pull in
asm-generic/barrier.h instead.
This sta
20 matches
Mail list logo
