> Linux doesn't ever run the cpu in the RMO memory model any more. All
> sparc64 chips run only in TSO now.
>
> All of the Niagara chips implement an even stricter than TSO memory
> model, and the membars we used to have all over the kernel to handle
> that properly were just wasted I-cache space.
From: Eric Botcazou
Date: Tue, 28 Jun 2011 23:27:43 +0200
> With the pristine compiler, the test passes with -mcpu=v9 but fails otherwise.
> It passes with the patched compiler. However, I suspect that we would still
> have problems with newer UltraSparc CPUs supporting full RMO, because the ne
> Fair enough, you can add this code if you want.
Thanks. Note that this is marginal for Solaris as GCC defaults to -mcpu=v9 on
Solaris but, in all other cases, it defaults to -mcpu=v8. I can reproduce the
problem on the SPARC/Linux machine 'grobluk' of the CompileFarm:
cpu : TI U
From: Eric Botcazou
Date: Tue, 28 Jun 2011 10:11:03 +0200
> The V8 architecture manual is quite clear about it: TSO allows stores to be
> reordered after subsequent loads (it's the only difference in TSO with Strong
> Consistency) so you need to do something to have a full memory barrier. As
> Let's clarify something, did you run your testcase that triggered this
> bug on a v8 or a v9 machine?
Sun UltraSPARC, so V9 of course. The point is that Solaris is TSO (TSO as
defined for the V9 architecture, i.e. backward compatible with V8) so you have
a V8-compatible TSO implementation, in
From: Geert Bosch
Date: Mon, 27 Jun 2011 23:17:18 -0400
>> \You then go on to speak about LEON, does LEON implement PSO?
> No, I'm not talking about PSO anywhere or SPARCv9 anywhere.
> Just plain old SPARCv8, using the TSO model. This requires a
> load-store instruction to guarantee a full memor
On Jun 27, 2011, at 22:45, David Miller wrote:
> From: Geert Bosch
> Date: Mon, 27 Jun 2011 22:21:47 -0400
>
>> On Jun 27, 2011, at 19:53, David Miller wrote:
>>
>>> Adding a ldstub here is going to be really expensive, on UltraSparc
>>> that can be 36+ cycles even on a cache hit.
>>
>> Yes,
From: David Miller
Date: Mon, 27 Jun 2011 19:45:33 -0700 (PDT)
> You then go on to speak about LEON, does LEON implement PSO?
BTW, even if it does, I would be encouraging the person who submits
LEON kernel patches to not run the chip in this mode.
We don't even use PSO for v9 chips, it's just n
From: Geert Bosch
Date: Mon, 27 Jun 2011 22:21:47 -0400
> On Jun 27, 2011, at 19:53, David Miller wrote:
>
>> Adding a ldstub here is going to be really expensive, on UltraSparc
>> that can be 36+ cycles even on a cache hit.
>
> Yes, synchronization in multi-CPU systems is expensive.
> If it's
On Jun 27, 2011, at 19:53, David Miller wrote:
> I'm trying to find the part of the v8 manual that says there is
> a situation where we should use "stbar" and a "ldstub" to implement
> proper memory barriers. In particular I'm looking in Appendix J,
> "Programming with the memory models." Where
From: Geert Bosch
Date: Mon, 27 Jun 2011 19:36:06 -0400
> On Jun 27, 2011, at 19:00, David Miller wrote:
>
>> V8 can only reorder stores, that's why it only has a 'stbar'
>> instruction. I'm not so sure I agree with trying to paper over the
>> fact that someone has compiled code for v8 that's
On Jun 27, 2011, at 19:00, David Miller wrote:
> V8 can only reorder stores, that's why it only has a 'stbar'
> instruction. I'm not so sure I agree with trying to paper over the
> fact that someone has compiled code for v8 that's going to run on a v9
> cpu.
That's not the issue. While it is t
From: Eric Botcazou
Date: Mon, 27 Jun 2011 18:11:10 +0200
> * config/sparc/sync.md (*stbar): Delete.
> (*membar_v8): New insn to implement UNSPEC_MEMBAR in SPARC-V8.
Code which cares about memory ordering etc. really has to know
the kind of cpu it is running on.
This is why atomic a
13 matches
Mail list logo
