Re: [RFC] MMIO accessors & barriers documentation

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Please explain what drivers will need changes because of this.  Not just
> the few you really care about, but _all_ that could be plugged into  
> PowerPC
> machines' PCI busses, and might need changes because of changing the
> ordering semantics of readX()/writeX() from the supposed standard Linux
> semantics (i.e., the x86 semantics).

They won't. They will still work, and in some (many ?) case better due
to the removal of a potential bug since lots of driver don't have a
barrier where they should be with relaxed semantics. So the net effect
is positive here.

Now, it also means that we -can- start improving drivers we care about
to use the relaxed semantics and benefit from there. And since the
semantics are well defined, all archs with some sort of relaxed ordering
will be able to benefit in a way or another.

In addition, it will allow us to get a small optimisation on PowerPC vs.
the current situation by slightly relaxing wmb() which currently has to
do a full sync because it might be used to order memory vs. MMIO, which
it will no longer do (it will go back to a pure memory store barrier).

Anyway, Paul has a patch we are testing that makes our writel/readl's
synchronous (by moving the sync to before writel, adding an eieio before
readl, and doing the percpu trick so spin_unlock magically does a sync
when a writel occurred). With that, we'll get full correctness with no
more sync's in writel than we had before. We are running some benchs
here now to see what kind of performance impact it has overall, and if
we are happy, that can make it into 2.6.18 and close the problem of
drivers assuming ordered MMIO vs. memory at least.

Then, in a -separate- step, we can provide a set of relaxed accessors
that will allow for additional performance improvements on the hot path
of selected drivers.

I'm tired of arguing over and over again the same thing here anyway,
I'll post a new version of the document including some of the feedback
we got already and will submit it for inclusion along with a
__writel/__readl implementation for powerpc (and a generic one that
defaults to readl/writel) for the 2.6.19 timeframe.

We'll see from there if there are more constructive comments.

Ben.