linux-mips
[Top] [All Lists]

Re: mips octeon memory model questions

To: Peter Zijlstra <peterz@infradead.org>
Subject: Re: mips octeon memory model questions
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 4 Feb 2014 11:16:58 -0800
Cc: David Daney <ddaney@caviumnetworks.com>, Ralf Baechle <ralf@linux-mips.org>, "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, linux-mips <linux-mips@linux-mips.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Paul McKenney <paulmck@linux.vnet.ibm.com>, Will Deacon <will.deacon@arm.com>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oGS/qi8cNlKwaZtYufsHAQ+oJuIWhWItpwsBJkLk+wY=; b=e1o2oUawBW5uV3HAl7C9gnvQbqfjzajfgYDkdylB5oSRE/EhNeI+cBgzMvHbAB8xu6 d7gUH6Q8LUizsbiMfWrm26bwR7gQmUA0DeyHWgsc85/hNl3PB2Y/fPHzNIq02SiWHnmW z7hUkJ9zDdfofDE82+RPv2lLoLbrmYLbwDJcDxSiDAib0sSCE2ogdaZeXdXdRNHSF58h Qts2KYt19LeN1AGwRfzeYQEtckLPWbHQwjkV7KwMH2yWNhOufpkf0scfDbYECBaqZiXM xbN8cU2OEVp3KiRoECEiCt4xNs8kKq9mgJIwI3ylx7kVf1e5RAgDLtYAFqaJID/I6ysw KPRA==
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oGS/qi8cNlKwaZtYufsHAQ+oJuIWhWItpwsBJkLk+wY=; b=E40enm9JQitBe3s52IstfeGnsKtM3cMrM9KxYXno/lbC3jcsvSnFr3VFRI/0g9TziR IOOqP7TMN87OJrEisWxYaRTZmW8sRP2xTc/BB+50DVQLt07FfrqqE7hVPilkh1vNADwd vgvw4oV9wkXZDHU13EWZpDSeVynvSlRm90Z6E=
In-reply-to: <20140204190535.GC5002@laptop.programming.kicks-ass.net>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20140204184150.GB5002@laptop.programming.kicks-ass.net> <CA+55aFz9+AtK_OnUhH0gspUsXLxZN-MRwKVR5zVPsVGmGpBqxg@mail.gmail.com> <20140204190535.GC5002@laptop.programming.kicks-ass.net>
Sender: linux-mips-bounce@linux-mips.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

<Prev in Thread] Current Thread [Next in Thread>