Prev: hla set up for the art of assembly
Next: Randy??? :)
From: H. Peter Anvin on 12 Jun 2008 17:20
Wolfgang Kern wrote:
>
> Yes, so I misunderstood your note on 'serializing by I/O access' ...
> and my check on writeable PCI memory ranges will still need some
> data cache invalidation, but I may find anything better than WBINVD.
>

Well, for P6+, cacheability is determined by the MTRRs (and PAT, if it's
in use.)

-hpa
From: H. Peter Anvin on 12 Jun 2008 17:23
James Harris wrote:
>
> Do you mean they are serializing purely because they are slow and thus
> allow any write buffers to drain to memory? If so I'm a little
> uncomfortable with this. What's to stop a PC being manufactured which
> has faster I/O? Some of the PCI ports can be memory speed, can they
> not?
>
> Or am I mixing up two concepts...?

An uncached access (which includes port I/O) will drain all buffers and
write combiners ahead of it, in order to produce an in-order sequence of
events visible to external devices. They are serializing against main
memory as seen by other CPUs and the DMA transactor, but do not flush
caches.

-hpa
From: Wolfgang Kern on 12 Jun 2008 21:23

H. Peter Anvin wrote:

>> Yes, so I misunderstood your note on 'serializing by I/O access' ...
>> and my check on writeable PCI memory ranges will still need some
>> data cache invalidation, but I may find anything better than WBINVD.

> Well, for P6+, cacheability is determined by the MTRRs (and PAT,
> if it's in use.)

my AMD-sets (CPU & bridges) got this as well, but I try to avoid
machine-dependent code whenever possible.
I think about to disable caching and use only one single WBINVD
in front of all these tests, because they are 'run-once' anyway.

__
wolfgang




From: H. Peter Anvin on 13 Jun 2008 17:25
Rod Pemberton wrote:
>
>> I/Os are almost always *effectively* serializing, just because they take
>> so long (they really are slow, or the chipset combination forces them to
>> be slow to have legacy behavior) I/Os do also have defined ordering
>> effects on some blocks (store buffer, etc), but are not truly
>> "serializing instructions".
>
> Sandpile.org calls these "store buffer draining" on the same page.
>

Yes, although it's more than the store buffer: they also flush write
combiners ahead of a store.

-hpa
 | 
Pages: 1
Prev: hla set up for the art of assembly
Next: Randy??? :)