From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751962AbdJESWR (ORCPT ); Thu, 5 Oct 2017 14:22:17 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:44756 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751886AbdJESWO (ORCPT ); Thu, 5 Oct 2017 14:22:14 -0400 Date: Thu, 5 Oct 2017 11:22:04 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com, oleg@redhat.com Subject: Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays Reply-To: paulmck@linux.vnet.ibm.com References: <20171004212915.GA10089@linux.vnet.ibm.com> <1507152575-11055-1-git-send-email-paulmck@linux.vnet.ibm.com> <20171005094114.yoqkhndfwidczfqj@hirez.programming.kicks-ass.net> <20171005145513.GO3521@linux.vnet.ibm.com> <20171005153913.5wanmnfmi6i3byv7@hirez.programming.kicks-ass.net> <20171005161909.GS3521@linux.vnet.ibm.com> <20171005162514.moaa24mn2pkto5fv@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171005162514.moaa24mn2pkto5fv@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17100518-0036-0000-0000-000002765A91 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007847; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000235; SDB=6.00926907; UDB=6.00466351; IPR=6.00707158; BA=6.00005623; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017409; XFM=3.00000015; UTC=2017-10-05 18:22:09 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17100518-0037-0000-0000-000041FC58AE Message-Id: <20171005182204.GT3521@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-05_08:,, 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-1707230000 definitions=main-1710050253 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 05, 2017 at 06:25:14PM +0200, Peter Zijlstra wrote: > On Thu, Oct 05, 2017 at 09:19:09AM -0700, Paul E. McKenney wrote: > > > > Yes, the ordering does need to be visible to uninvolved CPUs, so > > release-acquire is not necessarily strong enough. > > Why? Because I'm not at all seeing why it needs more. Your Changelog > doesn't provide enough hints. Hmmm... Here is what I was worried about: C C-PaulEMcKenney-W+RWC4+2017-10-05 { } P0(int *a, int *x) { WRITE_ONCE(*a, 1); smp_mb(); /* Lock acquisition for rcu_node ->lock. */ WRITE_ONCE(*x, 1); } P1(int *x, int *y, spinlock_t *l) { r3 = READ_ONCE(*x); smp_mb(); /* Lock acquisition for rcu_node ->lock. */ spin_lock(l); /* Locking in complete(). */ WRITE_ONCE(*y, 1); spin_unlock(l); } P2(int *y, int *b, spinlock_t *l) { spin_lock(l); /* Locking in wait_for_completion. */ r4 = READ_ONCE(*y); spin_unlock(l); r1 = READ_ONCE(*b); } P3(int *b, int *a) { WRITE_ONCE(*b, 1); smp_mb(); r2 = READ_ONCE(*a); } exists (1:r3=1 /\ 2:r4=1 /\ 2:r1=0 /\ 3:r2=0) My concern was that P2()'s read from b could be pulled into the lock's critical section and reordered with the read from y. But even if you physically rearrange the code, the cycle is forbidden. Removing P2()'s lock acquisition and release does allow the cycle. I get the same result when replacing spin_lock() with xchg_acquire() and spin_unlock() with smp_store_release(). I can drop P1()'s smp_mb() (but otherwise like the original above) and the cycle is forbidden. Removing P1()'s lock acquisition and release, but leaving the smp_mb(), does allow the cycle. So it looks like I can drop this patch entirely. Though somewhat nervously, despite the evidence that I have ample redundancy in ordering. ;-) So, thank you for persisting on this one! Thanx, Paul