The whole point of us doing DMA is to allow a device to place data into RAM
for a CPU to read it based on an external event. Otherwise, we would have
to poll the device. While that may be fine on a single CPU system running
only one task, it doesn't work well when we have multiple CPUs performing
I/O to PCI devices and running simulations. Having one CPU poll the bus is
detremental to that effort. That is why DMA is necessary. Even if it is
only ONE word.
Also, the people who pointed me to the patches and the newbie website were
extremely helpful. It turns out that I wasn't doing the MAP_NR and
mem_map_reserve. Also, it appears as if our SBS board doesn't support DMA
(the brochure said it did....., oh well).
Thanks,
Anthony Mayhall
Boeing Phantom Works
(256)876-2204
-----Original Message-----
From: Jes Sorensen [mailto:jes@linuxcare.com]
Sent: Wednesday, June 14, 2000 10:59 AM
To: root@chaos.analogic.com
Cc: Jeff Garzik; Mayhall, Tony; linux-kernel@vger.rutgers.edu
Subject: Re: PCI DMA into USER space
>>>>> "Richard" == Richard B Johnson <root@chaos.analogic.com> writes:
Richard> On 14 Jun 2000, Jes Sorensen wrote:
>> Rubbish, PCI shared memory is *slow* you want DMA. Granted, PCI
>> shared
Richard> Hardly rubbish.
PCI shared memory is slow
>> memory is faster than the brain dead IO ports but it's far from as
>> fast as streaming DMA or in particular host memory access. In a
>> modern PC you easily get 300-400MB/sec of real bandwidth between
>> the CPU and
Richard> You can easily get over 1,000 MB/sec between RAM and the
Richard> CPU. This is relevent only during a copy operation. It has
Richard> nothing to do with DMA.
For pure reads, I am talking copy speed - granted my numbers are
pretty old and based on P2 boxes. Easily get over 1GB/sec on a PCs
however ... well it's not easy.
>> system memory whereas you'll get far less than 100MB/sec when
>> accessing the PCI memory (maybe half if you're lucky). As such it
>> is
Richard> A 33MHz, 32-bit Revision 2.2-compliant PCI bus gives you 132
Richard> MB/second. That's the spec. There is no way to slow it down
Richard> except by a disconnect.
Would you do us all a favor and go read the PCI specs then? You'll
*theoretically* get 132MB/sec if you do *streaming* DMA, there is no
way in hell you'll get that with indiidual CPU transactions. PCI was
designed for streaming access not for random access.
>> quite often worth it to DMA to host memory and then let the CPU
>> access data from there.
Richard> Not ever. The DMA controllers can't work at CPU speed because
Richard> they can't keep the bus forever like the CPU can. The fly-by
Richard> mode supported by some chips allows you to get one transfer
Richard> per clock. The clock is only 16 MHz (max), not the 33 MHz of
Richard> PCI (some PCI even do 66 MHz although they are doing it on
Richard> "invented" specifications).
You're soo funny today, even if we for a second run around and
naiively believe we'll get 132MB/sec out of the PCI bus with CPU
random access then that is going to eat all your CPU cycles. If you on
the other hand DMA data to system memory and let the memory controller
fetch it in asynchronously with the CPU, it'll eat maybe a
significantly lower percentage of the total bandwidth and that will be
left over for the CPU to play with.
Jes
-
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