Quoting Tvrtko Ursulin (2018-03-27 09:51:20) > > On 26/03/2018 12:50, Chris Wilson wrote: > > Install a timer when trying to preempt on behalf of an important > > context such that if the active context does not honour the preemption > > request within the desired timeout, then we reset the GPU to allow the > > important context to run. > > I suggest renaming patch title to "Implement optional preemption delay > timeout", or "upper bound", or something, as long as it is not "force > preemption". :) > > > (Open: should not the timer be started from receiving the high priority > > request...) > > If you think receiving as in execbuf I think not - that would be > something else and not preempt timeout. I'm thinking of submit_request -> [insert huge delay] -> ksoftirqd. Actually I think it's better just to solve the ksoftirqd adding random delays since it affects us all over the shop. The tricky part is that I expect any request to improve (i.e. avoid) ksoftirqd for our use case is likely to end up in "use threaded-irq" with which we always incur a scheduler delay as we then do not have our irq_exit hook. I currently hack kernel/softirq.c to always run at least one loop for HI_SOFTIRQ before deferring to ksoftirqd. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
