Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936452AbdGTMw0 (ORCPT ); Thu, 20 Jul 2017 08:52:26 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:57514 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936208AbdGTMwY (ORCPT ); Thu, 20 Jul 2017 08:52:24 -0400 Date: Thu, 20 Jul 2017 05:52:19 -0700 From: "Paul E. McKenney" To: Boqun Feng Cc: Akira Yokosawa , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] documentation: Fix two-CPU control-dependency example Reply-To: paulmck@linux.vnet.ibm.com References: <0d60072f-3848-a2b7-ce18-e1ed317b5c09@gmail.com> <20170719174334.GH3730@linux.vnet.ibm.com> <101f5108-663e-7fa4-ac2b-e790320e4e6f@gmail.com> <20170719215602.GK3730@linux.vnet.ibm.com> <20170720013112.fmrml6abdhi2nqdt@tardis> <20170720054704.GM3730@linux.vnet.ibm.com> <20170720061434.zjjrkkdu7cqkxx6c@tardis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170720061434.zjjrkkdu7cqkxx6c@tardis> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17072012-0056-0000-0000-000003AA3BE0 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007392; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00890285; UDB=6.00444784; IPR=6.00670452; BA=6.00005481; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016296; XFM=3.00000015; UTC=2017-07-20 12:52:21 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17072012-0057-0000-0000-000007E05381 Message-Id: <20170720125219.GO3730@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-20_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707200198 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2086 Lines: 80 On Thu, Jul 20, 2017 at 02:14:34PM +0800, Boqun Feng wrote: > On Wed, Jul 19, 2017 at 10:47:04PM -0700, Paul E. McKenney wrote: > [...] > > > Hi Paul, > > > > > > I know the compiler could optimize atomics in very interesting ways, but > > > this case is about volatile, so I guess our case is still fine? ;-) > > > > Hello, Boqun, > > > > When I asked that question, the answer I got was "the compiler must > > emit the load instruction, but is under no obligation to actually use the > > value loaded". > > > > I don't happen to like that answer, by the way. ;-) > > > > Me neither, seems to me the kernel happens to work well at > compiler-optimization's mercy ;-/ > > With claim like that, compiler could do optimization as turning: > > struct task_struct *owner; > > for (;;) { > owner = READ_ONCE(lock->owner); > if (owner && !mutex_spin_on_owner(lock, owner)) > break; > /* ... */ > > into: > > struct task_struct *owner; > > owner = READ_ONCE(lock->owner); > > for (;;READ_ONCE(lock->owner)) { > if (owner && !mutex_spin_on_owner(lock, owner)) > break; > /* ... */ > > Because the load executed in every loop, and they just happen to choose > not to use the values. And this is within their rights! Well, this is one reason that I attend standards-committee meetings. As does Will Deacon. That way, there is someone there to protest when people argue that the above behavior is just fine. ;-) Thanx, Paul > Regards, > Boqun > > > Thanx, Paul > > > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0062r1.html > > > > > > > > > > Great material to wake up mind in the morning! Thanks. > > > > > > Regards, > > > Boqun > > > > > > > What are your thoughts on this? > > > > > > > > Thanx, Paul > > > > > > > > > Thanks, Akira > > > > > > > > > > > That said, I very much welcome critical reviews of memory-barriers.txt, > > > > > > so please do feel free to continue doing that! > > > > > > > > > > > > Thanx, Paul > > > > > > > > > > > > > > > > > > > > > > > > > > >