svn commit: r197643 - in head/sys: kern sys

[Rafal Jaworowski]

On 2009-10-01, at 15:41, Stanislav Sedov wrote:

> On Thu, 1 Oct 2009 15:21:34 +0200
> Attilio Rao <attilio at freebsd.org> mentioned:
>
>> 2009/9/30 Robert Watson <rwatson at 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