Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2529554ybl; Mon, 19 Aug 2019 03:36:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqy2zPbANfPU8+im7fDhd1Mr6bJKqn50VIRGdwvYH6HyOlhjX0c791V4R/o1FtvQ1ip2696h X-Received: by 2002:a17:90a:ec12:: with SMTP id l18mr19328498pjy.6.1566210987710; Mon, 19 Aug 2019 03:36:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566210987; cv=none; d=google.com; s=arc-20160816; b=Nztwk68tC1Hm52mTLuI4lBNuA0sGW8GYJeY+4izIlAwu699VUcE3qzo4oKC0cFP/M/ cEftPcrXmlVUvO8+eXkYUxeWsUBP/fwp4deJUevaqrWtQORyEIWuUEuQ7xLEtDbS0ljP kQmJrtK4E+ZnaZHtJNbj9Q0yTcQZ+uFoRFehcaVGR1+Phfc3BbSD+2fzwqY/nBdSiQAl WZJ1tnzGiNy1QnOsXMtSQiGH+aDF3uBZ1iOK607taa50tynp9Dfqiud1VhjhNAwmLQBe i0W+miPjCg4CmcufIJ38NO5hdGPAw6GICU73jrw1ftcKqmMSvrHd1Af8+pcZI0uRBDE2 X9BA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=5k7x7501Y9ASR62zgu7rgepmqDdfbrb4DRTTFPJ8MxQ=; b=NbKOa7v5xdAkH96WKdlDRNIUCLujpeNGWETCdObWjSy01VZfknw7MHI8aB1m1a6maC RTS0AtOwJ537ywFA3CrcokOE1ZUrOjVubkg6DauUcBvtmwCQGc5/SZiftMOr48rRBEgS DzZ0UHy1SOdawsESdI7QGgju61xFt5G+T5NTCCsFMNSYGgBUOKhPpc0pd/CmmiJ12Y8q AN/G7eIwy6wuu/j796nEXlb9EZBWXFsDvnAbn2lcHEhBdQxUI4+lvdztGyQrYFqdxp6p zZqBrYgld1gS0gMNpcbrX5yVD3c5gAh032C+CNsoZaT1QHliX3qKX0o4axRkZ+1Kv/G6 TxqQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v45si9669720pgn.10.2019.08.19.03.36.12; Mon, 19 Aug 2019 03:36:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727128AbfHSKev (ORCPT + 99 others); Mon, 19 Aug 2019 06:34:51 -0400 Received: from foss.arm.com ([217.140.110.172]:52222 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726477AbfHSKev (ORCPT ); Mon, 19 Aug 2019 06:34:51 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B538B344; Mon, 19 Aug 2019 03:34:50 -0700 (PDT) Received: from [10.1.194.37] (e113632-lin.cambridge.arm.com [10.1.194.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 454FC3F706; Mon, 19 Aug 2019 03:34:49 -0700 (PDT) Subject: Re: [PATCH 1/1] Fix: trace sched switch start/stop racy updates To: paulmck@linux.ibm.com Cc: Mathieu Desnoyers , Linus Torvalds , "Joel Fernandes, Google" , Thomas Gleixner , Alan Stern , rostedt , linux-kernel , Peter Zijlstra , Boqun Feng , Will Deacon , David Howells References: <241506096.21688.1565977319832.JavaMail.zimbra@efficios.com> <20190816205740.GF10481@google.com> <3c0cb8a2-eba2-7bea-8523-b948253a6804@arm.com> <20190817045217.GZ28441@linux.ibm.com> <1065930957.23914.1566054178444.JavaMail.zimbra@efficios.com> <600fd72f-11a0-ff1a-c87a-b26349f6f54a@arm.com> <20190817230034.GK28441@linux.ibm.com> From: Valentin Schneider Message-ID: Date: Mon, 19 Aug 2019 11:34:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190817230034.GK28441@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/08/2019 00:00, Paul E. McKenney wrote: [...] > Linus noted that he believes that compilers for architectures supporting > Linux can be trusted to avoid store-to-load transformations, invented > stores, and unnecessary store tearing. Should these appear, Linus would > report a bug against the compiler and expect it to be fixed. > >> I'll be honest, it's not 100% clear to me when those optimizations can >> actually be done (maybe the branch thingy but the others are dubious), and >> it's even less clear when compilers *actually* do it - only that they have >> been reported to do it (so it's not made up). > > There is significant unclarity inherent in the situation. The standard > says one thing, different compilers do other things, and developers > often expect yet a third thing. And sometimes things change over time, > for example, the ca. 2011 dictim against compilers inventing data races. > > Hey, they didn't teach me this aspect of software development in school, > either. ;-) > Gotta keeps things "interesting" somehow, eh... Thanks for the clarifications. > Thanx, Paul >