[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180329092046.GB22926@arm.com>
Date: Thu, 29 Mar 2018 10:20:47 +0100
From: Will Deacon <will.deacon@....com>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Nicholas Piggin <npiggin@...il.com>,
David Miller <davem@...emloft.net>, paulmck@...ux.vnet.ibm.com,
arnd@...db.de, linux-rdma@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linus971@...il.com,
alexander.duyck@...il.com, okaya@...eaurora.org, jgg@...pe.ca,
David.Laight@...lab.com, oohall@...il.com, netdev@...r.kernel.org,
alexander.h.duyck@...hat.com, torvalds@...ux-foundation.org
Subject: Re: RFC on writel and writel_relaxed
On Thu, Mar 29, 2018 at 08:31:32AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-29 at 02:23 +1000, Nicholas Piggin wrote:
> > This is a variation on the mandatory write barrier that causes writes to weakly
> > ordered I/O regions to be partially ordered. Its effects may go beyond the
> > CPU->Hardware interface and actually affect the hardware at some level.
> >
> > How can a driver writer possibly get that right?
> >
> > IIRC it was added for some big ia64 system that was really expensive
> > to implement the proper wmb() semantics on. So wmb() semantics were
> > quietly downgraded, then the subsequently broken drivers they cared
> > about were fixed by adding the stronger mmiowb().
> >
> > What should have happened was wmb and writel remained correct, sane, and
> > expensive, and they add an mmio_wmb() to order MMIO stores made by the
> > writel_relaxed accessors, then use that to speed up the few drivers they
> > care about.
> >
> > Now that ia64 doesn't matter too much, can we deprecate mmiowb and just
> > make wmb ordering talk about stores to the device, not to some
> > intermediate stage of the interconnect where it can be subsequently
> > reordered wrt the device? Drivers can be converted back to using wmb
> > or writel gradually.
>
> I was under the impression that mmiowb was specifically about ordering
> writel's with a subsequent spin_unlock, without it, MMIOs from
> different CPUs (within the same lock) would still arrive OO.
>
> If that's indeed the case, I would suggest ia64 switches to a similar
> per-cpu flag trick powerpc uses.
... or we could remove ia64.
/me runs for cover
Will
Powered by blists - more mailing lists