Linux中的DMA memcpy操作

Question

我想dma使用dmaengine.c文件(linux/drivers/dma)中的dma_async_memcpy_buf_to_buf函数.为此,我在dmatest.c文件(linux/drivers/dma)中添加了一个函数,如下所示:

void foo ()
{
    int index = 0;
    dma_cookie_t cookie;
    size_t len = 0x20000;

    ktime_t start, end, end1, end2, end3;
    s64 actual_time;    

    u16* dest;
    u16* src;

    dest = kmalloc(len, GFP_KERNEL);
    src = kmalloc(len, GFP_KERNEL);

    for (index = 0; index < len/2; index++)
    {
        dest[index] = 0xAA55;
        src[index] = 0xDEAD;
    }

    start = ktime_get();
    cookie = dma_async_memcpy_buf_to_buf(chan, dest, src, len);

    while (dma_async_is_tx_complete(chan, cookie, NULL, NULL) == DMA_IN_PROGRESS)
    {
       dma_sync_wait(chan, cookie);
    }
    end = ktime_get();
    actual_time = ktime_to_ns(ktime_sub(end, start));
    printk("Time taken for function() execution     dma: %lld\n",(long long)actual_time);   

    memset(dest, 0 , len);

    start = ktime_get();
    memcpy(dest, src, len);

    end = ktime_get();
    actual_time = ktime_to_ns(ktime_sub(end, start));
    printk("Time taken for function() execution non-dma: %lld\n",(long long)actual_time);
}

DMA存在一些问题:

1. 有趣的是,memcpy函数执行时间小于dma_async_memcpy_buf_to_buf函数.也许,它与ktime_get()函数问题有关.

2. 使用foo函数的方法是正确的还是不正确的以执行DMA操作？我不确定这个.

3. 如何根据cpu使用情况测量memcpy和dma_async_memcpy_buf_to_buf函数的滴答计数

4. 最后,在应用程序级别是否可以进行DMA操作？到目前为止我在内核级别使用,如上所示(dmatest.c是插入内核模块)

Answer 1

您的问题中存在多个问题,这使得您很难准确回答您的质疑:

1. 是的,您的一般DMA操作调用算法是正确的.

2. 使用普通memcpy和DMA操作复制内存的根本区别在于没有获得直接的性能提升,但是(a)由于在使用DMA操作时维持CPU缓存/预取器状态而导致性能提升(使用普通旧时memcpy执行时可能会出现乱码,执行在CPU本身),和(b)真正的后台操作,让CPU可用于做其他事情.

3. 给定(a),对低于CPU高速缓存大小的任何东西(即几十兆字节)使用DMA操作是没有意义的.通常,它是为了快速脱离CPU流处理而完成的,即移动无论如何由外部设备生成/消费的数据,例如快速网络卡,视频流/捕获/编码硬件等.

4. 根据挂钟经过的时间比较异步和同步操作是错误的.可能有数百个线程/进程正在运行,并且没有人保证您将在下一个时间点进行安排,而不是在数千个时钟之后.

5. 使用ktime_get为基准目的是错误的-这是相当不准确的,特别是对给定这样的短作业.事实上,分析内核代码是一项非常困难和复杂的任务,这远远超出了这个问题的范围.这里的一个快速建议是完全克制这些微观基准并描述一个更大更完整的工作 - 类似于你最终想要实现的目标.

6. 虽然您可以使用特定于CPU供应商的工具,例如英特尔的VTune,但测量现代CPU的"滴答"也是毫无意义的.

7. 在应用程序级别上使用DMA复制操作是毫无意义的 - 至少我不能带来一个可靠的场景,当它值得一试时.它本身并不快,而且,更重要的是,我严重怀疑应用程序性能的瓶颈是内存复制.对于这种情况,你通常应该比常规内存复制更快地完成所有其他事情,而且我真的不能在应用程序级别上想到任何比这更快的内容memcpy.如果我们谈论与其他一些非CPU处理设备的通信,那么它自动不是应用程序级别.

8. 通常,存储器复制性能通常受存储器速度的限制,即时钟频率和时序.你不会memcpy在直接性能方面获得任何奇迹提升,因为memcpy在CPU上执行的速度足够快,因为CPU通常比内存工作时钟频率高3x-5x-10倍.