Hi Javier, On Wed, Aug 17, 2016 at 02:28:56PM -0400, Javier Martinez Canillas wrote: > The vb2_buffer_done() function can be called from interrupt context but it > currently calls the vb2 memory allocator .finish operation to sync buffers > and this can take a long time, so it's not suitable to be done there. > > This patch defers part of the vb2_buffer_done() logic to a worker thread > to avoid doing the time consuming operation in interrupt context. I agree the interrupt handler is not the best place to perform the work in vb2_buffer_done() (including cache flushing), but is a work queue an ideal solution? The work queue task is a regular kernel thread not subject to sched_setscheduler(2) and alike, which user space programs can and do use to change how the scheduler treats these processes. Requiring a work queue to be run between the interrupt arriving from the hardware and the user space process being able to dequeue the related buffer would hurt use cases where strict time limits are crucial. Neither I propose making the work queue to have real time priority either, albeit I think might still be marginally better. Additionally, the work queue brings another context switch per dequeued buffer. This would also be undesirable on IoT and mobile systems that often handle multiple buffer queues simultaneously. Performing this task in the context of the process that actually dequeues the buffer avoids both of these problem entirely as there are no other processes involved. -- Kind regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
