Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752045AbaBRTAv (ORCPT ); Tue, 18 Feb 2014 14:00:51 -0500 Received: from mail-ve0-f169.google.com ([209.85.128.169]:45954 "EHLO mail-ve0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751558AbaBRTAt (ORCPT ); Tue, 18 Feb 2014 14:00:49 -0500 MIME-Version: 1.0 In-Reply-To: References: <1392486310.18779.6447.camel@triegel.csb> <1392666947.18779.6838.camel@triegel.csb> <530296CD.5050503@warwick.ac.uk> <1392737465.18779.7644.camel@triegel.csb> <20140218171609.GP4250@linux.vnet.ibm.com> Date: Tue, 18 Feb 2014 11:00:48 -0800 X-Google-Sender-Auth: GxpmhCjv5mNzXMs8ppbZ-aAjQ1A Message-ID: Subject: Re: [RFC][PATCH 0/5] arch: atomic rework From: Linus Torvalds To: Peter.Sewell@cl.cam.ac.uk Cc: Paul McKenney , Torvald Riegel , Alec Teal , Will Deacon , Peter Zijlstra , Ramana Radhakrishnan , David Howells , "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "mingo@kernel.org" , "gcc@gcc.gnu.org" 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 18, 2014 at 10:23 AM, Peter Sewell wrote: > > interesting list. So are you saying that value-range-analysis and > such-like (I say glibly, without really knowing what "such-like" > refers to here) are fundamentally incompatible with > the kernel code No, it's fine to do things like value-range-analysis, it's just that you have to do it on a local scope, and not think that you can see every single write to some variable. And as Paul points out, this is actually generally true even outside of kernels. We may be pretty unique in having some things that are literally done by hardware (eg the page table updates), but we're certainly not unique in having loadable modules or code that the compiler doesn't know about by virtue of being compiled separately (assembly files, JITted, whatever). And we are actually perfectly fine with compiler barriers. One of our most common barriers is simply this: #define barrier() __asm__ __volatile__("": : :"memory") which basically tells the compiler "something changes memory in ways you don't understand, so you cannot assume anything about memory contents". Obviously, a compiler is still perfectly fine optimizing things like local variables etc that haven't had their address taken across such a barrier (regardless of whether those local variables might be spilled to the stack frame etc), but equally obviously we'd require that this kind of thing makes sure that any atomic writes have been finalized by the time the barrier happens (it does *not* imply a memory ordering, just a compiler memory access barrier - we have separate things for ordering requirements, and those obviously often generate actual barrier instructions) And we're likely always going to have things like this, but if C11 atomics end up working well for us, we might have *fewer* of them. Linus -- 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/