Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754394AbbDPSYk (ORCPT ); Thu, 16 Apr 2015 14:24:40 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:38102 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751426AbbDPSYc (ORCPT ); Thu, 16 Apr 2015 14:24:32 -0400 Date: Thu, 16 Apr 2015 20:24:27 +0200 From: Ingo Molnar To: Peter Zijlstra Cc: Steven Rostedt , Mel Gorman , Rik van Riel , Jason Low , Linus Torvalds , Thomas Gleixner , linux-kernel@vger.kernel.org, "Paul E. McKenney" , Andrew Morton , Oleg Nesterov , Mike Galbraith , Frederic Weisbecker , Mel Gorman , Preeti U Murthy , hideaki.kimura@hp.com, Aswin Chandramouleeswaran , Scott J Norton Subject: Re: [PATCH 1/3] sched, timer: Remove usages of ACCESS_ONCE in the scheduler Message-ID: <20150416182426.GA17852@gmail.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150416181535.GA23123@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2169 Lines: 55 * 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. > > And while the effects here might end up being statistical noise, I > have conceptual problems with re-reading seq counts, that's not > proper. Yes ... but that still leaves this weird feeling that it's really still a bit wrong because it's not proper parallel code, we just reduced the probability of the remaining races radically. And it's not like GCC (or any compiler) does load tearing or even store tearing under normal -O2 for such code patterns, right? > > And its not like they really cost anything. That's true. Would it make sense to add a few comments to the seq field definition site(s), about how it's supposed to be accessed - or to the READ_ONCE()/WRITE_ONCE() sites, to keep people from wondering? Thanks, Ingo -- 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/