2018-07-23 21:57 GMT+03:00 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Mon, 23 Jul 2018, Matwey V. Kornilov wrote: > >> I've tried to strategies: >> >> 1) Use dma_unmap and dma_map inside the handler (I suppose this is >> similar to how USB core does when there is no URB_NO_TRANSFER_DMA_MAP) > > Yes. > >> 2) Use sync_cpu and sync_device inside the handler (and dma_map only >> once at memory allocation) >> >> It is interesting that dma_unmap/dma_map pair leads to the lower >> overhead (+1us) than sync_cpu/sync_device (+2us) at x86_64 platform. >> At armv7l platform using dma_unmap/dma_map leads to ~50 usec in the >> handler, and sync_cpu/sync_device - ~65 usec. >> >> However, I am not sure is it mandatory to call >> dma_sync_single_for_device for FROM_DEVICE direction? > > According to Documentation/DMA-API-HOWTO.txt, the CPU should not write > to a DMA_FROM_DEVICE-mapped area, so dma_sync_single_for_device() is > not needed. Well, I measured the following at armv7l. The handler execution time (URB_NO_TRANSFER_DMA_MAP is used for all cases): 1) coherent DMA: ~3000 usec (pwc is not functional) 2) explicit dma_unmap and dma_map in the handler: ~52 usec 3) explicit dma_sync_single_for_cpu (no dma_sync_single_for_device): ~56 usec So, I suppose that unfortunately Tomasz suggestion doesn't work. There is no performance improvement when dma_sync_single is used. At x86_64 the following happens: 1) coherent DMA: ~2 usec 2) explicit dma_unmap and dma_map in the handler: ~3.5 usec 3) explicit dma_sync_single_for_cpu (no dma_sync_single_for_device): ~4 usec So, whats to do next? Personally, I think that DMA streaming API introduces not so great overhead. Does anybody happy with turning to streaming DMA or I'll introduce module-level switch as Ezequiel suggested? > > Alan Stern > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
