Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4287670ybi; Mon, 3 Jun 2019 08:28:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqyHzt02g5Y0WR89uRrCMj/GrGggsRP8XKqkoRmtNxa/iT6zC15CNGQSyRVHvb0fGflvNOK7 X-Received: by 2002:a63:1d1d:: with SMTP id d29mr29784356pgd.63.1559575722914; Mon, 03 Jun 2019 08:28:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559575722; cv=none; d=google.com; s=arc-20160816; b=I4z3ndG6wV7+KhrnLwc94mhr3yxDeh/4A+IdAXiKxcbpVsr7FL91LSFMp9b3ag9nq4 72x0pnmUzJy4NJjv2STVKVlkUGm6ydHLpgVLbGqYlWWTp4mXaSFgoJSD/pHCqHjGMsra EnUOST4Tffu9VTt0WzucamewloL4Z3IVeYeASOOepIcZuLHtpDSUWx6vlvkZJJwLHSrW IcXc5RgbjtLUKPsiP7RBvLbISVXGLLEBHWTZRaRFu2BCZbHMJOCcVdUqSAFIxCnS/7UR gJL9DhlCVkGGmrmoHvUqxGMtldvtc9K2R2+m4HuHjk5UT2PRFVhzlA1Zgo3T2lIrmESx nwEA== 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:mime-version :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:subject:cc:to:from; bh=QsQh4b4hO6pfF4DDil9kw1l2MDTU3/DKoBEcNvkzLh8=; b=o58X81w91KOiQgZARvDgNIorOzZpgtTLbduiXwVBh3vJ1pW11pIKgzfxcaR0GwNQ9j n7poyh6xOl9jIrXzBQt/OTLiZ9kDYA2Pq1cIQKEGwqYGFGYj5dxseeflXjOwGkVlX08n 8665pk4/C5WC91M0ad+BRYekKtDOrzyL3f1sIZ4xSP5XoWLfUoAXIpn2WhN1IsLGsLIm f8V+Mk/Z2MTqHzbYndeyFWRp0trGENE79d22yhw2ec4wMA39lRVXutmVlIdJYNcLPdlI +QWMC5goPsU733jFNE1FsIsLT8whQQSHsrQYJinaoF8CpnDErZLMxs/07iOkeiwc0nvj lmpA== 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 b3si19020162pgd.243.2019.06.03.08.28.25; Mon, 03 Jun 2019 08:28:42 -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 S1727407AbfFCP0H convert rfc822-to-8bit (ORCPT + 99 others); Mon, 3 Jun 2019 11:26:07 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]:50908 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726989AbfFCP0H (ORCPT ); Mon, 3 Jun 2019 11:26:07 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-206-3Kexq_UPNJK4r62qVQ50LA-1; Mon, 03 Jun 2019 16:26:02 +0100 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b::d117) by AcuMS.aculab.com (fd9f:af1c:a25b::d117) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 3 Jun 2019 16:26:01 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Mon, 3 Jun 2019 16:26:01 +0100 From: David Laight To: "'paulmck@linux.ibm.com'" , Herbert Xu CC: Linus Torvalds , Frederic Weisbecker , Boqun Feng , Fengguang Wu , LKP , LKML , Netdev , "David S. Miller" Subject: RE: rcu_read_lock lost its compiler barrier Thread-Topic: rcu_read_lock lost its compiler barrier Thread-Index: AQHVGehFXRQXDDgADEmCdQtcecKZ/qaJ/5iA Date: Mon, 3 Jun 2019 15:26:01 +0000 Message-ID: <9c0a9e2faae7404cb712f57910c8db34@AcuMS.aculab.com> References: <20150910171649.GE4029@linux.vnet.ibm.com> <20150911021933.GA1521@fixme-laptop.cn.ibm.com> <20150921193045.GA13674@lerouge> <20150921204327.GH4029@linux.vnet.ibm.com> <20190602055607.bk5vgmwjvvt4wejd@gondor.apana.org.au> <20190603024640.2soysu4rpkwjuash@gondor.apana.org.au> <20190603034707.GG28207@linux.ibm.com> <20190603040114.st646bujtgyu7adn@gondor.apana.org.au> <20190603072339.GH28207@linux.ibm.com> <20190603084214.GA1496@linux.ibm.com> In-Reply-To: <20190603084214.GA1496@linux.ibm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-MC-Unique: 3Kexq_UPNJK4r62qVQ50LA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Paul E. McKenney > Sent: 03 June 2019 09:42 ... > On kissing the kernel goodbye, a reasonable strategy might be to > identify the transformations that are actually occuring (like the > stores of certain constants called out above) and fix those. > We do > occasionally use READ_ONCE() to prevent load-fusing optimizations that > would otherwise cause the compiler to turn while-loops into if-statements > guarding infinite loops. In that case the variable ought to be volatile... > There is also the possibility of having the > compiler guys give us more command-line arguments. I wonder how much the code size (of anything) would increase if the compiler: 1) Never read a value into a local more than once. 2) Never write a value that wasn't requested by the code. 3) Never used multiple memory accesses for 'machine word' (and smaller) items. (1) makes all reads READ_ONCE() except that the actual read can be delayed until further down the code. If I have a naive #define bswap32() I'd expect: v = bswap32(foo->bar) to possibly read foo->bar multiple times, but not: int foo_bar = foo->bar; v = bswap32(foo_bar); (2) makes all writes WRITE_ONCE() except that if there are multiple writes to the same location, only the last need be done. In particular it stops speculative writes and the use of locations that are going to be written to as temporaries. It also stop foo->bar = ~0; being implemented as a clear then decrement. (3) I'd never imagined the compiler would write the two halves of a word separately! If the compiler behaved like that (as one might expect it would) then READ_ONCE() would be a READ_NOW() for when the sequencing mattered. I was also recently surprised by the code I got from this loop: for (i = 0; i < limit; i++) sum64 += array32[i]; (as in the IP checksum sum without add carry support). The compiler unrolled it to used horrid sequences of sse3/avx instructions. This might be a gain for large enough buffers and 'hot cache' but for small buffer and likely cold cache it is horrid. I guess such optimisations are valid, but I wonder how often they are an actual win for real programs. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)