[lkml]   [2019]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Re: [RFC][PATCH 2/5] mips/atomic: Fix loongson_llsc_mb() wreckage

>On Tue, May 14, 2019 at 8:58 AM Peter Zijlstra <> wrote:
>> So if two variables share a line, and one is local while the other is
>> shared atomic, can contention on the line, but not the variable, cause
>> issues for the local variable?
>> If not; why not? Because so far the issue is line granular due to the
>> coherence aspect.
>If I understood the issue correctly, it's not that cache coherence
>doesn't work, it's literally that the sc succeeds when it shouldn't.
>In other words, it's not going to affect anything else, but it means
>that "ll/sc" isn't actually truly atomic, because the cacheline could
>have bounced around to another CPU in the meantime.
>So we *think* we got an atomic update, but didn't, and the "ll/sc"
>pair ends up incorrectly working as a regular "load -> store" pair,
>because the "sc' incorrectly thought it still had exclusive access to
>the line from the "ll".
>The added memory barrier isn't because it's a memory barrier, it's
>just keeping the subsequent speculative instructions from getting the
>cacheline back and causing that "sc" confusion.
>But note how from a cache coherency standpoint, it's not about the
>cache coherency being wrong, it's literally just about the ll/sc not
>giving the atomicity guarantees that the sequence is *supposed* to
>give. So an "atomic_inc()" can basically (under just the wrong
>circumstances) essentially turn into just a non-atomic "*p++".
Agreed,that is exactly what I was learned.

>NOTE! I have no actual inside knowledge of what is going on. The above
>is purely my reading of this thread, and maybe I have mis-understood.

you got it right.
>                  Linus
 \ /
  Last update: 2019-05-15 15:53    [W:0.085 / U:4.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site