Hello, On Fri, Apr 17, 2020 at 04:16:28PM -0400, Lyude Paul wrote: > Hey Tejun! So I ended up rewriting the drm_vblank_work stuff so that it used > kthread_worker. Things seem to work alright now. But while we're doing just > fine with vblank workers on nouveau, we're still having trouble meeting the > time constraints needed for using vblank works for i915's needs. There still > seems to be a considerable latency between when the irq handler for the vblank > interrupts fires, and when the actual drm_vblank_work we scheduled starts: ... > Tejun, do you have any idea if we might be able to further reduce the latency > from the scheduler here? I believe we're already using pm_qos to at least > reduce the latency between when the vblank interrupt fires and the interrupt > handler starts, but that still isn't enough to fix the other latency issues > apparently. We're also already setting the priority of kthread_worker->task to > RT_FIFO as well. I don't think the kernel can do much better than what you're seeing. I don't know the time scale that you need - is it some tens of microseconds range? I'm definitely not an expert on the subject but on generic kernels I don't think you can achieve anything sub millisec with any kind of reliability. If the timing is that tight and it's not a hot path, the right solution may be polling for it rather than yielding the cpu and hoping to get scheduled in time. > Also, of course, let me know if you're not happy with the > __kthread_queue_work() changes/kthread_worker usage in drm_vblank_work as well Just glanced over it and I still wonder whether it needs to be that tightly integrated, but we can look into that once we settle on whether this is the right direction. Thanks. -- tejun _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
