From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753383AbbIERxX (ORCPT ); Sat, 5 Sep 2015 13:53:23 -0400 Received: from casper.infradead.org ([85.118.1.10]:41521 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752487AbbIERxP (ORCPT ); Sat, 5 Sep 2015 13:53:15 -0400 Date: Sat, 5 Sep 2015 19:53:02 +0200 From: Peter Zijlstra To: Linus Torvalds Cc: Chris Metcalf , Thomas Gleixner , Will Deacon , Oleg Nesterov , Paul McKenney , Ingo Molnar , "mtk.manpages@gmail.com" , "dvhart@infradead.org" , "dave@stgolabs.net" , "Vineet.Gupta1@synopsys.com" , "ralf@linux-mips.org" , "ddaney@caviumnetworks.com" , "linux-kernel@vger.kernel.org" , Russell King - ARM Linux , Richard Henderson Subject: Re: futex atomic vs ordering constraints Message-ID: <20150905175302.GV3644@twins.programming.kicks-ass.net> References: <20150826181659.GW16853@twins.programming.kicks-ass.net> <20150901163140.GK1612@arm.com> <20150901164247.GO16853@twins.programming.kicks-ass.net> <20150902125555.GT16853@twins.programming.kicks-ass.net> <55E71F92.4000001@ezchip.com> <20150902170008.GU19282@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 02, 2015 at 02:18:53PM -0700, Linus Torvalds wrote: > So I think we could possibly relax the requirements (and document this > very clearly) to say that the futex operation must be totally ordered > wrt any other _user_space_ accesses by that thread. I suspect a lot of > architectures can then say "we may be very weakly ordered, but kernel > entry/exit implies enough synchronization that we do not need any > futher memory barriers". Right, so before sending this email I actually spoke to Ralf about this option, and he said that this is not actually well defined for MIPS. But we could certainly document it such and let archs for which this is well documented (I would expect this to be most) choose that implementation.