Re: [PATCH 2/3] MIPS: enforce LL-SC loop enclosing with SYNC (ACQUIRE and RELEASE)

[Leonid Yegoshin <Leonid.Yegoshin@xxxxxxxxxx>]

On 06/02/2015 04:39 AM, James Hogan wrote:

Hi Leonid,

On 02/06/15 01:09, Leonid Yegoshin wrote:

CPUs may occasionally have problems in accordance with HW team.

"have problems in accordance with HW team" is a bit confusing. What do
you mean?

I wrote about memory barriers and problems may happens without it.
Some details from internal e-mail exchange:

-------------------------------------------

yes, it is possible for the stores to be observed out of order
The SC B can complete if it has ownership and the SW A is still
waiting for ownership.  This scenario was also possible on older
cores.

(snip)

-----Original Message-----
From: Leonid Yegoshin 
Subject: more SYNC issues

...

I want to know - do XXXX orders stores without SYNC?

Let's consider a scenario:

SW    $0, A (cache miss)
...
LL    $1, B (cache hit)
..
SC    $1, B (cache hit again)
B        (is not taken!)
..
SYNC  0x10

Is it possible for other core to get new value of B before new value of A between SC-B and SYNC? 
-------------------------------------------------------------

Another mail, another processor:

==========================================

Hi Leonid

 I looked into the LSU RTL and I do not see speculation being blocked for younger loads following LL.

 I also ran a testcase to confirm my observation:

LL  (cacheable)  Miss

LW (cacheable)  Miss, different cacheline

Miss request for LW goes out before the Miss request for LL, also the GPR updated for LW happens before the LL GPR update.
==========================================

Actually *true*? P5600 you mean? Same in Kconfig help text.

Yes, thank you, it is P5600 and I5600 doesn't exist.

It feels wrong to be giving the user this option. Can't we just select
WEAK_REORDERING_BEYOND_LLSC automatically based on the hardware that
needs to be supported by the kernel configuration (e.g. CPU_MIPSR6 or
CPU_MIPS32_R2)?

No, we can't - a lot of old processors are in-order and all of that is still MIPS R2.

 Those who care about mips r2 performance on hardware
which doesn't strictly need it can always speak up / add an exception.

Out of interest, are futex operations safe with weak llsc ordering, on
the premise that they're mainly used by userland so ordering with normal
kernel accesses just doesn't matter in practice?

I think futex is used to communicate between user threads and problem is theoretically still here.

This patch does 3 logically separable things:
1) add smp_release/smp_acquire based on MIPS_LIGHTWEIGHT_SYNC and weaken
smp_store_release()/smp_load_acquire() to use them.
2) weaken llsc barriers when MIPS_LIGHTWEIGHT_SYNC.
3) the MIPS_ENFORCE_WEAK_REORDERING_BEYOND_LLSC Kconfig stuff (or
whatever method to select WEAK_REORDERING_BEYOND_LLSC more often).

Any reason not to split them, and give a clear description of each?

I don't see a reason to split it.

- Leonid.