On 2009-10-01, at 15:41, Stanislav Sedov wrote:
On Thu, 1 Oct 2009 15:21:34 +0200
Attilio Rao <atti...@freebsd.org> mentioned:
2009/9/30 Robert Watson <rwat...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
