[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160104160455.GE17861@jhogan-linux.le.imgtec.org>
Date: Mon, 4 Jan 2016 16:04:55 +0000
From: James Hogan <james.hogan@...tec.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: "Michael S. Tsirkin" <mst@...hat.com>,
<linux-kernel@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
<linux-arch@...r.kernel.org>,
Andrew Cooper <andrew.cooper3@...rix.com>,
<virtualization@...ts.linux-foundation.org>,
Stefano Stabellini <stefano.stabellini@...citrix.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
David Miller <davem@...emloft.net>,
<linux-ia64@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>,
<linux-s390@...r.kernel.org>, <sparclinux@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-metag@...r.kernel.org>, <linux-mips@...ux-mips.org>,
<x86@...nel.org>, <user-mode-linux-devel@...ts.sourceforge.net>,
<adi-buildroot-devel@...ts.sourceforge.net>,
<linux-sh@...r.kernel.org>, <linux-xtensa@...ux-xtensa.org>,
<xen-devel@...ts.xenproject.org>, "Ingo Molnar" <mingo@...nel.org>,
Davidlohr Bueso <dbueso@...e.de>,
Andrey Konovalov <andreyknvl@...gle.com>
Subject: Re: [PATCH v2 20/32] metag: define __smp_xxx
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:
> > 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.
>
> > 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
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists