Re: [v3,11/41] mips: reuse asm-generic/barrier.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
<address dep>
Wy = 1

P2:
Ry == 1
<address dep>
Rx = 0


So are you saying that this is also forbidden?
Imagine that P0 and P1 are two threads that share a store buffer. What
then?

OK, I collected answers and it is:

In MIPS R6 this test passes OK, I mean - P2: Rx = 1 if Ry is read as 1. By design.

    However, it is unclear that happens in MIPS R2 1004K.

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" examples which require SYNC_RMB between loading address/index and using that for loading data based on that address or index for shared data (look on CPU2 pseudo-code):
To deal with this, a data dependency barrier or better must be inserted
between the address load and the data load:

        CPU 1                 CPU 2
        ===============       ===============
        { A == 1, B == 2, C = 3, P == &A, Q == &C }
        B = 4;
        <write barrier>
        WRITE_ONCE(P, &B);
                              Q = READ_ONCE(P);
<data dependency barrier> <----------- SYNC_RMB is here
                              D = *Q;
...
Another example of where data dependency barriers might be required is where a number is read from memory and then used to calculate the index for an array
access:

        CPU 1                 CPU 2
        ===============       ===============
        { M[0] == 1, M[1] == 2, M[3] = 3, P == 0, Q == 3 }
        M[1] = 4;
        <write barrier>
        WRITE_ONCE(P, 1);
                              Q = READ_ONCE(P);
<data dependency barrier> <------------ SYNC_RMB is here
                              D = M[Q];

That voices say that there is a legitimate reason to relax HW here for performance if SYNC_RMB is needed anyway to work with this sequence of shared data.


And all that is out-of-topic here in my mind. I just want to be sure that this patchset still provides a use of a specific lightweight SYNCs on MIPS vs bold and heavy generalized "SYNC 0" in any case.

- Leonid.





[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux