Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754728AbbBQSXm (ORCPT <rfc822;w@1wt.eu>);
	Tue, 17 Feb 2015 13:23:42 -0500
Received: from casper.infradead.org ([85.118.1.10]:33401 "EHLO
	casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753867AbbBQSXl (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 17 Feb 2015 13:23:41 -0500
Date: Tue, 17 Feb 2015 19:23:35 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Kirill Tkhai <ktkhai@parallels.com>, linux-kernel@vger.kernel.org,
        Ingo Molnar <mingo@redhat.com>, Josh Poimboeuf <jpoimboe@redhat.com>,
        oleg@redhat.com
Subject: Re: [PATCH 2/2] [PATCH] sched: Add smp_rmb() in task rq locking
 cycles
Message-ID: <20150217182335.GQ5029@twins.programming.kicks-ass.net>
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>
 <20150217160532.GW4166@linux.vnet.ibm.com>
 <20150217180154.GA28082@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150217180154.GA28082@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1488
Lines: 41

On Tue, Feb 17, 2015 at 10:01:54AM -0800, Paul E. McKenney wrote:
> > > The blob under SMP BARRIER PAIRING does not mention pairing with control
> > > dependencies; and I'm rather sure I've done so.
> 
> And here is a patch for the control-dependency pairing.  Thoughts?

The proposed patch does not change the blub under SMP BARRIER PAIRING,
which would be the first place I would look for this.

> @@ -850,6 +853,19 @@ Or:
>  			      <data dependency barrier>
>  			      y = *x;
>  
> +Or even:
> +
> +	CPU 1		      CPU 2
> +	===============	      ===============================
> +	r1 = ACCESS_ONCE(y);
> +	<write barrier>
> +	ACCESS_ONCE(y) = 1;   if (r2 = ACCESS_ONCE(x)) {
> +			         <implicit control dependency>
> +			         ACCESS_ONCE(y) = 1;
> +			      }
> +
> +	assert(r1 == 0 || r2 == 0);
> +
>  Basically, the read barrier always has to be there, even though it can be of
>  the "weaker" type.

Does that want to be a <general barrier>; CPU1 looks to do a LOAD
followed by a STORE, separated by a WMB, which is of course odd.

To me the pairing with a general barrier is also the most intuitive,
since the control dependency is a LOAD -> STORE order.

Then again, I'm rather tired and maybe I'm missing the obvious :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/