On 07/19/2016 07:20 PM, Russell King - ARM Linux wrote: >> vchan_cookie_complete() will only mark the cookie completed, adds the vd to >> the desc_completed list (it was deleted from desc_issued list when it was >> started by omap_dma_start_desc) and schedule the tasklet to deal with the real >> completion later. >> Marking the just finished descriptor/cookie done first then looking for >> possible descriptors in the queue to start feels like a better sequence. > > I deliberately arranged the code in the original order so that the next > transfer was started on the hardware with the least amount of work by > the CPU. Yes, there may not be much in it, but everything you mention > above adds to the number of CPU cycles that need to be executed before > the next transfer can be started. > > More CPU cycles wasted means higher latency between transfers, which > means lower performance. OK. I will drop this patch in v2. >> After a quick grep in the kernel source: only omap-dma.c was starting the >> next transfer before marking the current completed descriptor/cookie done. > > Right, because I've thought about the issue, having been the author of > both virt-dma and omap-dma. > -- Péter -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
