ioatdma

ioatdma

[Bernd Schubert]

Hello,

from my understanding of ioatdma it just should be loaded before raid456 to 
make use it, shouldn't it?

I just wonder why memcpy_count and bytes_transferred in /sys/class/dma/* is 
always zero.

I guess the kernel version is relevant, but this a bit difficult to answer, 
since we have backported a huge chunk of raid, ioatdma and dca to 2.6.22...


Do I miss something?


Thanks,
Bernd

-- 
Bernd Schubert
Q-Leap Networks GmbH

ioatdma

[Bernd Schubert]

Hello,

from my understanding of ioatdma it just should be loaded before raid456 to 
make use it, shouldn't it?

I just wonder why memcpy_count and bytes_transferred in /sys/class/dma/* is 
always zero.

I guess the kernel version is relevant, but this a bit difficult to answer, 
since we have backported a huge chunk of raid, ioatdma and dca from 2.6.25
to 2.6.22...


Do I miss something or do I need to enable something somewhere?


Thanks,
Bernd

Re: ioatdma

[Dan Williams]

On Wed, Mar 19, 2008 at 2:57 AM, Bernd Schubert <bs@q-leap.de> wrote:
> Hello,
>
>  from my understanding of ioatdma it just should be loaded before raid456 to
>  make use it, shouldn't it?
>
>  I just wonder why memcpy_count and bytes_transferred in /sys/class/dma/* is
>  always zero.
>

Currently only network traffic will update these counts.  They are not
currently hooked up for the raid/async_tx case.  NET_DMA uses
dma_async_memcpy_*() whereas MD uses async_memcpy().

In my tests with the iop-adma driver on an iop342.  I look at
/proc/interrupts to check that things are alive and kicking.

You could add the following to async_memcpy():
        cpu = get_cpu();
        per_cpu_ptr(chan->local, cpu)->bytes_transferred += len;
        per_cpu_ptr(chan->local, cpu)->memcpy_count++;
        put_cpu();


--
Dan