From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933002AbcH2MzL (ORCPT ); Mon, 29 Aug 2016 08:55:11 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:33249 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756715AbcH2MzA (ORCPT ); Mon, 29 Aug 2016 08:55:00 -0400 Subject: Re: [PATCH 1/4] spinlock: Document memory barrier rules To: Peter Zijlstra References: <1472385376-8801-1-git-send-email-manfred@colorfullife.com> <1472385376-8801-2-git-send-email-manfred@colorfullife.com> <20160829104815.GI10153@twins.programming.kicks-ass.net> Cc: benh@kernel.crashing.org, paulmck@linux.vnet.ibm.com, Ingo Molnar , Boqun Feng , Andrew Morton , LKML , 1vier1@web.de, Davidlohr Bueso From: Manfred Spraul Message-ID: <968e4c62-4486-a6aa-8fdf-67ff9b05a330@colorfullife.com> Date: Mon, 29 Aug 2016 14:54:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160829104815.GI10153@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, On 08/29/2016 12:48 PM, Peter Zijlstra wrote: > On Sun, Aug 28, 2016 at 01:56:13PM +0200, Manfred Spraul wrote: >> Right now, the spinlock machinery tries to guarantee barriers even for >> unorthodox locking cases, which ends up as a constant stream of updates >> as the architectures try to support new unorthodox ideas. >> >> The patch proposes to reverse that: >> spin_lock is ACQUIRE, spin_unlock is RELEASE. >> spin_unlock_wait is also ACQUIRE. >> Code that needs further guarantees must use appropriate explicit barriers. >> >> Architectures that can implement some barriers for free can define the >> barriers as NOPs. >> >> As the initial step, the patch converts ipc/sem.c to the new defines: >> - no more smp_rmb() after spin_unlock_wait(), that is part of >> spin_unlock_wait() >> - smp_mb__after_spin_lock() instead of a direct smp_mb(). >> > Why? This does not explain why.. Which explanation is missing? - removal of the smb_rmb() after spin_unlock_wait? What about: > - With commit 2c6100227116 > ("locking/qspinlock: Fix spin_unlock_wait() some more"), > (and the commits for the other archs), spin_unlock_wait() is an > ACQUIRE. > Therefore the smp_rmb() after spin_unlock_wait() can be removed. > - smp_mb__after_spin_lock() instead of a direct smp_mb(). > This allows that architectures override it with a less expensive > barrier if this is sufficient for their hardware. - Why smp_mb is required after spin_lock? See Patch 02, I added the race that exists on real hardware. Exactly the same issue exists for sem.c - Why introduce a smp_mb__after_spin_lock()? The other options would be: - same as RCU, i.e. add CONFIG_PPC into sem.c and nf_contrack_core.c - overhead for all archs by added an unconditional smp_mb() -- Manfred