Quoting Mika Kuoppala (2018-05-07 09:54:27)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-05-07 09:34:24)
> >> Chris Wilson writes:
> >>
> >> > We rely on ksoftirqd to run in a timely fashion in order to drain the
> >> > execlists queue. Quite frequently, it does not. In some cases w
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-05-07 09:34:24)
>> Chris Wilson writes:
>>
>> > We rely on ksoftirqd to run in a timely fashion in order to drain the
>> > execlists queue. Quite frequently, it does not. In some cases we may see
>> > latencies of over 200ms triggering our idle
Quoting Mika Kuoppala (2018-05-07 09:34:24)
> Chris Wilson writes:
>
> > We rely on ksoftirqd to run in a timely fashion in order to drain the
> > execlists queue. Quite frequently, it does not. In some cases we may see
> > latencies of over 200ms triggering our idle timeouts and forcing us to
>
Chris Wilson writes:
> We rely on ksoftirqd to run in a timely fashion in order to drain the
> execlists queue. Quite frequently, it does not. In some cases we may see
> latencies of over 200ms triggering our idle timeouts and forcing us to
> declare the driver wedged!
>
> Thus we can speed up id
We rely on ksoftirqd to run in a timely fashion in order to drain the
execlists queue. Quite frequently, it does not. In some cases we may see
latencies of over 200ms triggering our idle timeouts and forcing us to
declare the driver wedged!
Thus we can speed up idle detection by bypassing ksoftirq
