On 2009-10-01, at 15:41, Stanislav Sedov wrote:
> On Thu, 1 Oct 2009 15:21:34 +0200
> Attilio Rao <attilio@freebsd.org> mentioned:
>
>> 2009/9/30 Robert Watson <rwatson@freebsd.org>:
>>> On Wed, 30 Sep 2009, Attilio Rao wrote:
>>>
>>>> When releasing a read/shared lock we need to use a write memory
>>>> barrier
>>>> in order to avoid, on architectures which doesn't have strong
>>>> ordered
>>>> writes, CPU instructions reordering.
>>>
>>> Hi Attilio (Fabio, et al),
>>>
>>> Nice catch! Are we aware of specific reported problems that can
>>> be laid at
>>> the feet of this bug, or was this more of a "wait a moment,
>>> shouldn't there
>>> be a barrier there?". Could you comment on the scope of this
>>> problem across
>>> architectures we support?
>>
>> A possible problem related to that would be MD specific and not on
>> ia32/amd64 because there the barriers and simple atomics are the
>> same.
>> Given that sun4v suffers of serveral other problems, that MIPS has no
>> SMP support, you would find it only for arm, ia64 and sparc
>> eventually. Thus I'm not aware of any problem which can be
>> reconducted
>> to that.
>>
>
> Actually, MIPS is going to grow SMP support really soon, and ARM cpus
> do not do reordering until ARMv7 afaik. So this should not result in
> any real problems on ARM too.
Even past generation ARM can do out-of-order execution: see Marvell
Feroceon cores which are v5 ISA compatible, although their internal
microarchitecture has extended features like this.
> OTOH, I suspect powerpc may be affected. I'm not sure if any of the
> models
> we support perform OOO, though.
PowerPC is inherently OOOE.
Rafal