On 10/07/20 08:57, Rob Clark wrote: > Yeah, I think we will end up making some use of uclamp.. there is > someone else working on that angle > > But without it, this is a case that exposes legit prioritization > problems with commit_work which we should fix ;-) I wasn't suggesting this as an alternative to fixing the other problem. But it seemed you had a different problem here that I thought I could help with :-) I did give my opinion about how to handle that priority issue. If the 2 threads are kernel threads and by design they need relative priorities IMO the kernel need to be taught to set this relative priority. It seemed the vblank worker could run as SCHED_DEADLINE. If this works, then the priority problem for commit_work disappears as SCHED_DEADLINE will preempt RT. If commit_work uses sched_set_fifo(), its priority will be 50, hence your SF threads can no longer preempt it. And you can manage the SF threads to be any value you want relative to 50 anyway without having to manage commit_work itself. I'm not sure if you have problems with RT tasks preempting important CFS tasks. My brain registered two conflicting statements. Thanks -- Qais Yousef _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
