[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory prefetch

Dave New wrote:
> In this case, a 'rep movsd' will indeed cause a burst, as long as
> you are writing, rather than reading from the PCI bus.  As a
> matter of interest, the Natoma (200MHz PentiumPro) chipset seems
> to be capable of arbitrarily long write bursts, which can play
> havoc with targets that may be counting on doing somthing else
> between bursts (like storing some of that data away, or doing
> some processing on it 8-).

I seem to remember that any device can burst as long as it's
latency timer hasn't expired or the arbiter hasn't removed
the grant signal (i.e. no one else asks for the bus). When we
looked at the issue some time back we found that some arbiter
would remove grant without reason, resulting in unnecessary
arbitration. So if no other party is requesting the bus and
the CPU is busy executing the rep movsd there is no reason to
terminate the burst. On the other hand, most non-CPU bus masters
will be stopped eventually by the CPU fetching instructions.

How do SMP chip sets handle the case where one CPU is bursting
data and another CPU needs to fetch instructions?
> Also, bursting data *from* the host memory *to* a PCI initiater is
> generally not supported by most host chipsets.  Intel cites
> host memory cache coherency complications as the reason for
> not supporting this.  That's a real limitation, in my opinion,
> since you must use the host processor to manually move the data
> from host memory to a PCI target, thus consuming the host CPU
> 100% during the transfer, or else move it piece-wise across
> the PCI bus, tying up the bus with 4 to 5 PCI bus clock cycles for
> every datum (byte, short, long) transferred (*that* will chop
> your 132 MByte/sec peak transfer rate down to size 8-).

Is this true for Read Line/Read Multiple operations as well?

Jochen Roth