Thread (85 messages) 85 messages, 12 authors, 2016-01-11

Re: [PATCH v2 20/32] metag: define __smp_xxx

From: James Hogan <hidden>
Date: 2016-01-04 16:05:04
Also in: linux-arch, linux-arm-kernel, linux-mips, linux-s390, linux-sh, linux-um, lkml, sparclinux

On Mon, Jan 04, 2016 at 04:30:36PM +0100, Peter Zijlstra wrote:
On Mon, Jan 04, 2016 at 03:25:58PM +0000, James Hogan wrote:
quoted
It is used along with the metag specific __global_lock1() (global
voluntary lock between hw threads) whenever a write is performed, and by
smp_mb/smp_rmb to try to catch other cases, but I've never been
confident this fixes every single corner case, since there could be
other places where multiple CPUs perform unsynchronised writes to the
same memory location, and expect cache not to become incoherent at that
location.
Ah, yuck, I thought blackfin was the only one attempting !coherent SMP.
And yes, this is bound to break in lots of places in subtle ways. We
very much assume cache coherency for SMP in generic code.
Well, its usually completely coherent, its just a bit dodgy in a
particular hardware corner case, which was pretty hard to hit, even
without these workarounds.
quoted
It seemed to be sufficient to achieve stability however, and SMP on Meta
Linux never made it into a product anyway, since the other hw thread
tended to be used for RTOS stuff, so it didn't seem worth extending the
generic barrier API for it.
*phew*, should we take it out then, just to be sure nobody accidentally
tries to use it then?
SMP support on this SoC you mean? I doubt it'll be a problem tbh, and
it'd work fine in QEMU when emulating this SoC, so I'd prefer to keep it
in.

Cheers
James

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help