On Wed, 14 Jun 2000, Russell King wrote:
> Richard B. Johnson writes:
> > A 33MHz, 32-bit Revision 2.2-compliant PCI bus gives you 132 MB/second.
> > That's the spec. There is no way to slow it down except by a disconnect.
>
> Can we be more precise here please? 132MB/s is not realistic if you're
> talking about most PCI shared memory implementations.
>
> Yes, its true that you might be able to achieve nearly full bandwidth when
> accessing ///prefetchable/// PCI memory, but most shared PCI memory is not
> prefetchable.
>
> "Prefetchable" means that the bridges can pull much data across the PCI
> bus and cache it, so that the next read does not cause a PCI transaction
> (eg, only one in 8 reads causes a transaction, but this depends on the
> setup).
No! This is a common misconseption! By default, all PCI transactions
are posted. Posting is not "pre-fetching". Pre-fetching is loading the
cache with data that has not yet been requested by the CPU to be read.
Pre-fetching is usually disabled in shared-memory areas regardless of
whether or not the device is on the PCI bus because you can get stale data
into the cache which has not yet been written by the device, and there is
no way for the cache-controller to "know".
Posting allows the device (or CPU) to send data, with a promise that
it will eventually get to where it's going. This means that when
the CPU gets to read data, there will be no wait-states until the
PCI FIFO is empty. This works well because, in the typical application,
(such as an Ethernet controller), writes to shared memory are "thought"
by the device to be completed while they are still data in the FIFO, not
yet written to SDRAM. The board interrupts the CPU and eventually the
CPU starts to read the data. Wait states are only incurred when the
CPU reads from SDRAM that has not yet been written by the PCI device.
This means that for the most part, the CPU gets to read from shared RAM
at SDRAM speeds, while the device gets to signal the CPU before the
actual transaction is complete. This can usually hide all of the
CPU overhead necessary to actually get to read from shared RAM
(interrupt latency, etc).
Cheers,
Dick Johnson
Penguin : Linux version 2.3.36 on an i686 machine (400.59 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:32 EST