From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752150AbbBQQFk (ORCPT ); Tue, 17 Feb 2015 11:05:40 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]:55573 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751707AbbBQQFi (ORCPT ); Tue, 17 Feb 2015 11:05:38 -0500 Date: Tue, 17 Feb 2015 08:05:32 -0800 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Kirill Tkhai , linux-kernel@vger.kernel.org, Ingo Molnar , Josh Poimboeuf , oleg@redhat.com Subject: Re: [PATCH 2/2] [PATCH] sched: Add smp_rmb() in task rq locking cycles Message-ID: <20150217160532.GW4166@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150217104516.12144.85911.stgit@tkhai> <1424170021.5749.22.camel@tkhai> <20150217121258.GM5029@twins.programming.kicks-ass.net> <20150217130523.GV24151@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150217130523.GV24151@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15021716-0005-0000-0000-000008DE0347 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 17, 2015 at 02:05:23PM +0100, Peter Zijlstra wrote: > On Tue, Feb 17, 2015 at 01:12:58PM +0100, Peter Zijlstra wrote: > > --- a/kernel/sched/core.c > > +++ b/kernel/sched/core.c > > @@ -341,6 +341,22 @@ static struct rq *task_rq_lock(struct ta > > raw_spin_lock_irqsave(&p->pi_lock, *flags); > > rq = task_rq(p); > > raw_spin_lock(&rq->lock); > > + /* > > + * move_queued_task() task_rq_lock() > > + * > > + * ACQUIRE (rq->lock) > > + * [S] ->on_rq = MIGRATING [L] rq = task_rq() > > + * WMB (__set_task_cpu()) ACQUIRE (rq->lock); > > + * [S] ->cpu = new_cpu [L] task_rq() > > + * [L] ->on_rq > > + * RELEASE (rq->lock) > > + * > > + * If we observe the old cpu in task_rq_lock, the acquire of > > + * the old rq->lock will fully serialize against the stores. > > + * > > + * If we observe the new cpu in task_rq_lock, the acquire will > > + * pair with the WMB to ensure we must then also see migrating. > > + */ > > if (likely(rq == task_rq(p) && !task_on_rq_migrating(p))) > > return rq; > > raw_spin_unlock(&rq->lock); > > Hey Paul, remember this: https://lkml.org/lkml/2014/7/16/310 I do now. ;-) > I just used a creative one :-) The scenario above? > BTW, should we attempt to include that table in memory-barriers.txt like > Mathieu said? As a cheat sheet with references to longer explanations > for the 'interesting' ones? > > FWIW, we should probably update that table to include control > dependencies too; we didn't (formally) have those back then I think. > > The blob under SMP BARRIER PAIRING does not mention pairing with control > dependencies; and I'm rather sure I've done so. Yep, they should pair as well, though the pairing is limited. No transitivity, of course. So the straightforward approach requires eighteen bits per cell, though some of them are a bit, ummm, "unusual". Sixteen of these are given by Scenarios 0-15 in http://lwn.net/Articles/573436/, with the barrier on the side corresponding to the first column and the barrier on the top corresponding to the second column. The seventeenth bit says whether you get transitivity chaining after the top access, assuming that it happens later. The eighteenth bit says whether you get transitivity chaining before the side access, assuming that it happens earlier. The following is a rough first guess, filling in only the diagonal. Some of the entries are no doubt wrong, and getting them right requires something like 7*7*18 test cases, which will take some time. So, is something like this really helpful? | mb | wmb | rmb | rbd | acq | rel | ctl | -----+-------+-------+-------+-------+-------+-------+-------+ mb | 3ffff | X | X | X | X | X | X + -----+-------+-------+-------+-------+-------+-------+-------+ wmb | X | 01000 | X | X | X | X | X + -----+-------+-------+-------+-------+-------+-------+-------+ rmb | X | X | 00000 | X | X | X | X + -----+-------+-------+-------+-------+-------+-------+-------+ rbd | X | X | X | 00000 | X | X | X + -----+-------+-------+-------+-------+-------+-------+-------+ acq | X | X | X | X | 00020 | X | X + -----+-------+-------+-------+-------+-------+-------+-------+ rel | X | X | X | X | X | 0cc00 | X + -----+-------+-------+-------+-------+-------+-------+-------+ ctl | X | X | X | X | X | X | 00020 + -----+-------+-------+-------+-------+-------+-------+-------+ Thanx, Paul