On Fri, 1 Jul 2005, Alan Cox wrote:
> > But that mentions compiler only, not CPU ordering! I understand the BIU
> > of the issuing CPU and any external hardware is still permitted to
> > merge/reorder these accesses unless separated by wmb()/rmb()/mb() as
>
> I think the practical situation is that this implies ordering to the bus
> interface. It might be interesting to ask the powerpc people their
> experience but looking at most PCI drivers they assume this and it would
> be expensive not to do so on x86.
Hmm, doing this OTOH would be expensive on platforms actually requiring
explicit barriers for this to be the case. The problem is only drivers
know what they expect, e.g. you may need as much as:
writel();
mb();
readl();
but only:
readl();
rmb();
readl();
With barriers coded explicitly in drivers, you may control this, with ones
inside these mmio functions/macros you need to use mb() everywhere as you
don't know what the surrounding operations are going to be. And mb() may
be significantly more expensive than rmb().
Of course to facilitate such explicit barriers for platforms where
inter-processor ordering rules are different to ones for mmio a different
set of operations would have to be defined -- actually we've already got
one, mmiowb(), as a starting point.
> > We have that iob() macro/call as well, so that you can push cycles out of
> > the CPU domain immediately as well, which is equivalent to:
>
> > mb();
> > make_host_complete_writes();
>
> My feeling is the default readb etc are __readb + mb + make_hos...
Hmm, barriers are normally expected to happen *before* affected
operations, which is natural and often much faster as in the case of
traditional MIPS write-back buffers, where there is no "flush" operation
and mb() is just a tight loop spinning on the WB condition non-empty,
e.g.: "0: bc0f 0b" till the buffer empties itself. So I'd rather make
readb() being mb() + make_host_complete_writes() + __readb(). But it
would be more painful performance-wise than necessary for many cases,
questioning the whole idea as any sane driver writer would prefer to use
these double-underscore calls and schedule barriers as necessary manually
anyway.
But if it's indeed what's intended I'd prefer it to be documented
somewhere in a reasonable place as there are people outside the Intel
world which may not necessarily know which interfaces imply Intel
semantics and which do not. ;-)
Maciej
|