Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932426AbaBDTRF (ORCPT ); Tue, 4 Feb 2014 14:17:05 -0500 Received: from mail-vb0-f46.google.com ([209.85.212.46]:54763 "EHLO mail-vb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932161AbaBDTQ7 (ORCPT ); Tue, 4 Feb 2014 14:16:59 -0500 MIME-Version: 1.0 In-Reply-To: <20140204190535.GC5002@laptop.programming.kicks-ass.net> References: <20140204184150.GB5002@laptop.programming.kicks-ass.net> <20140204190535.GC5002@laptop.programming.kicks-ass.net> Date: Tue, 4 Feb 2014 11:16:58 -0800 X-Google-Sender-Auth: 7Zp5duukBqkbbUqQluZ2PQ2c_eU Message-ID: Subject: Re: mips octeon memory model questions From: Linus Torvalds To: Peter Zijlstra Cc: David Daney , Ralf Baechle , "linux-arch@vger.kernel.org" , linux-mips , Linux Kernel Mailing List , Paul McKenney , Will Deacon Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 4, 2014 at 11:05 AM, Peter Zijlstra > >> So writes move down, not up. > > Right, but the ll-sc store might move down over a later store. Unlikely. The thing is, in order for the sc to succeed, it has to already have hit the cache coherency domain (or at least reserved it - ie maybe the value is not actually *in* the cache, but the sc needs to have gotten exclusive access to the cacheline). So just how do you expect a later store (that is *after* the conditional branch that tests the result of the sc) to move up before it? I'm not saying it's physically impossible: speculation is always possible. But it would require some rather clever speculative store buffers or caches and killing of same when mispredicted. Which is actually fairly unlikely, since stores are seldom - if ever - in the critical path. IOW, "lots and lots of effort for very little gain". So I'm personally quite willing to believe that a sc+conditional-branch+st is quite well ordered without any extra barriers. I'd be more worried about *reads* moving up past the sc ("doesn't reorder reads" to me would imply not moving across the "ll" part, but it's quite likely that the "sc" actually counts as both a read and a write). Without any visible documentation (see aforementioned "clown company" comment) all of this is obviously just pure speculation. Linus -- 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/