Re: Serializing memory with respect to IN/OUT

[David Laight <david%l8s.co.uk@localhost>]

On Thu, Nov 10, 2016 at 10:10:05AM -0600, David Young wrote:
> On Thu, Nov 10, 2016 at 10:52:54AM -0500, Mouse wrote:
> > But the code appears to work in practice.  So I'm clearly missing
> > something.  Have I just not found enough documentation to understand
> > all the effects of LOCK or the xFENCE instructions, or are IN and OUT
> > serialized as if they were memory accesses, or do things just delay
> > long enough that everything happens to get pushed in practice, or what?
> 
> As I recall, there is an interplay of PCI bus ordering rules and x86
> memory-ordering rules such that IN and OUT flush DMA buffers to the
> device.
> 
> Also, I think that the work performed by bus_dmamap_sync(9) on x86 is
> frequently redundant with a subsequent IN/OUT register access.  It's
> too bad, because I have seen bus_dmamap_sync rise near the top of
> profiles involving wm(4).  ISTR making a proposal about adding some
> bus_dmamap_sync(9) operations to help avoid redundant synchronization
> ops, but I probably got busy and stopped pursuing it.
> 
> Last time I looked at bus_dmamap_sync, I realized that while there is a
> DMA-coherent cache on x86, you have to take care with the write/store
> buffer.

X86 is pretty much bullet proof for memory coherency.
I think there are only 2 odd things the software has to worry about.
1) Specutive cpu memory reads can cause 'old data' be read.
2) Explicit (IIRC) write-combining access via the store buffer.

IIRC IN/OUT serialise other memory accesses - so are actually
slightly stronger than straight memory accesses.

Don't believe some old p-pro? docs which allowed all sorts
of re-ordering. No real cpu behaved that way.

	David

-- 
David Laight: david%l8s.co.uk@localhost