On Wed, Oct 07, 2020 at 05:30:10PM +0100, Qais Yousef wrote: > 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. I think the problem is there's two modes cros runs in: Normal cros mode, which mostly works like a linux desktop. CFS commit work seems fine. Other mode is android emulation, where we have the surface flinger thread running at SCHED_FIFO. I think Rob's plan is to runtime switch priorities to match each use case. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
