From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755973AbcBBSGi (ORCPT ); Tue, 2 Feb 2016 13:06:38 -0500 Received: from mail-io0-f180.google.com ([209.85.223.180]:35262 "EHLO mail-io0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751980AbcBBSGh (ORCPT ); Tue, 2 Feb 2016 13:06:37 -0500 MIME-Version: 1.0 In-Reply-To: <20160202175127.GO10166@arm.com> References: <20160129095958.GA4541@arm.com> <20160129102253.GG4503@linux.vnet.ibm.com> <20160201135621.GD6828@arm.com> <20160202035458.GF6719@linux.vnet.ibm.com> <20160202051904.GC1239@fixme-laptop.cn.ibm.com> <20160202064433.GG6719@linux.vnet.ibm.com> <20160202093440.GD1239@fixme-laptop.cn.ibm.com> <20160202175127.GO10166@arm.com> Date: Tue, 2 Feb 2016 10:06:36 -0800 X-Google-Sender-Auth: AaNRA85it_U50HW8Us-AU2l6dHk Message-ID: Subject: Re: [RFC][PATCH] mips: Fix arch_spin_unlock() From: Linus Torvalds To: Will Deacon Cc: Boqun Feng , Paul McKenney , Peter Zijlstra , "Maciej W. Rozycki" , David Daney , =?UTF-8?B?TcOlbnMgUnVsbGfDpXJk?= , Ralf Baechle , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 2, 2016 at 9:51 AM, Will Deacon wrote: > > Given that the vast majority of weakly ordered architectures respect > address dependencies, I would expect all of them to be hurt if they > were forced to use barrier instructions instead, even those where the > microarchitecture is fairly strongly ordered in practice. I do wonder if it would be all that noticeable, though. I don't think we've really had benchmarks. For example, most of the RCU list traversal shows up on x86 - where loads are already acquires. But they show up not because of that, but because a RCU list traversal is pretty much always going to take the cache miss. So it would actually be interesting to just try it - what happens to kernel-centric benchmarks (which are already fairly rare) on arm if we change the rcu_dereference() to be a smp_load_acquire()? Because maybe nothing happens at all. I don't think we've ever tried it. > As far as I understand it, the problems with "consume" have centred > largely around compiler and specification issues, which we don't have > with rcu_dereference (i.e. we ignore thin-air and use volatile casts > /barrier() to keep the optimizer at bay). Oh, I agree. The C++ consume orderings have been different from the kernel worries. But if it turns out that we have situations where we lose transitivity because of rcu_dereference not being an acquire, then we have kernel problems. I do see that your later email said that the pointer dependency (which we assume in rcu) should retain the transitivity, so maybe there is no real reason to strengthen things. But I _would_ argue that transitivity is so important (because of the whole "individual orderings make sense and are causal, so the end result must make sense and be causal") that if that were to break, then such an architecture really should just strengthen the orderings. Because the *worst* kinds of bugs are exactly the ones where the code makes sense and works locally, but then the combination of two or three pieces of code that are individually sensible ends up not working for some crazy non-transitivity reason. That really is not something that people can cope with. And maybe we will one day have widely available automated ordering proofs that work across the whole kernel, and we don't even need to worry about "this breaks peoples minds", but I don't think we are there yet. Linus