Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754609AbbFBSxr (ORCPT ); Tue, 2 Jun 2015 14:53:47 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:39589 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753970AbbFBSxk (ORCPT ); Tue, 2 Jun 2015 14:53:40 -0400 Message-ID: <556DFBAF.8020801@imgtec.com> Date: Tue, 2 Jun 2015 11:53:35 -0700 From: Leonid Yegoshin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "linux-kernel@vger.kernel.org >> LKML" , "linux-mips@linux-mips.org" Subject: Re: [PATCH 2/3] MIPS: enforce LL-SC loop enclosing with SYNC (ACQUIRE and RELEASE) References: <556DF959.1010704@imgtec.com> In-Reply-To: <556DF959.1010704@imgtec.com> X-Forwarded-Message-Id: <556DF959.1010704@imgtec.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.20.3.79] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3152 Lines: 108 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/