Message-ID: <1429218059.7039.173.camel@j-VirtualBox>
Subject: Re: [PATCH 1/3] sched, timer: Remove usages of ACCESS_ONCE in the
 scheduler
From: Jason Low <jason.low2@hp.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>, Steven Rostedt <rostedt@goodmis.org>,
        Mel Gorman <mel@csn.ul.ie>, Rik van Riel <riel@redhat.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>,
        Mike Galbraith <umgwanakikbuti@gmail.com>,
        Frederic Weisbecker <fweisbec@gmail.com>, Mel Gorman <mgorman@suse.de>,
        Preeti U Murthy <preeti@linux.vnet.ibm.com>, hideaki.kimura@hp.com,
        Aswin Chandramouleeswaran <aswin@hp.com>,
        Scott J Norton <scott.norton@hp.com>, jason.low2@hp.com
Date: Thu, 16 Apr 2015 14:00:59 -0700
In-Reply-To: <20150416181535.GA23123@twins.programming.kicks-ass.net>
References: <1429052986-9420-1-git-send-email-jason.low2@hp.com>
	 <1429052986-9420-2-git-send-email-jason.low2@hp.com>
	 <20150414195906.3adc89d9@gandalf.local.home>
	 <1429063953.7039.88.camel@j-VirtualBox>
	 <20150414224059.061ec5bf@grimm.local.home>
	 <20150415074601.GC13449@gmail.com>
	 <20150416165224.GD12676@worktop.ger.corp.intel.com>
	 <20150416180227.GB17401@gmail.com>
	 <20150416181535.GA23123@twins.programming.kicks-ass.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1842
Lines: 41

On Thu, 2015-04-16 at 20:15 +0200, Peter Zijlstra wrote:
> On Thu, Apr 16, 2015 at 08:02:27PM +0200, Ingo Molnar wrote:
> > > ACCESS_ONCE() is not a compiler barrier
> > 
> > It's not a general compiler barrier (and I didn't claim so) but it is 
> > still a compiler barrier: it's documented as a weak, variable specific 
> > barrier in Documentation/memor-barriers.txt:
> 
> Ok, fair enough. I just don't generally think of them as 'barriers'.
> 
> > > The 'read' side uses ACCESS_ONCE() for two purposes:
> > >  - to load the value once, we don't want the seq number to change under
> > >    us for obvious reasons
> > >  - to avoid load tearing and observe weird seq numbers
> > > 
> > > The update side uses ACCESS_ONCE() to avoid write tearing, and 
> > > strictly speaking it should also worry about read-tearing since its 
> > > not hard serialized, although its very unlikely to actually have 
> > > concurrency (IIRC).
> 
> > This is what I meant by that there's no harm from this race.
> 
> Ok, but I would still like to preserve the READ one on the usage site
> and the WRITE one on the update side, if only as documentation that
> there's something 'special' happening.

In that case, in our patch 2, I suppose we also want to use READ_ONCE()
when accessing the running field, which also helps document that we're
reading and writing to a non-atomic value that gets accessed without a
lock.

> And while the effects here might end up being statistical noise, I have
> conceptual problems with re-reading seq counts, that's not proper.
> 
> And its not like they really cost anything.

--
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/