Re: [RFC] drm/i915: Temporarily go realtime when polling PCODE

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 21/02/2017 18:48, Imre Deak wrote:
> On Tue, Feb 21, 2017 at 05:01:58PM +0000, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> Elevate task scheduling policy to realtime when polling on PCODE
>> to guarantee a good poll rate before falling back to busy wait.
>>
>> We only do this for tasks with normal policy and priority in
>> order  to simplify policy restore and also assuming that for
>> tasks which either made themselves low or high priority it makes
>> less sense to do so.
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Cc: Imre Deak <imre.deak@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> ---
>> This was my idea as mentioned in the other thread.
>>
>> Deadline scheduling policy seems trickier to restore from so
>> I thought SCHED_FIFO should be good enough.
>>
>> Briefly tested but couldn't reproduce the timeout condition.
>
> Hm, I thought you wanted this instead of the preempt-disable poll. The
> first preempt-enable poll is what's based on the spec, which only
> requires two requests 3ms apart, so no requirement on the number of
> requests there. That works most of the time and the preempt-disable part
> is needed only rarely. So do we want to increase the priority for the
> normal case?

So we end up in the busy loop case less often or never? (By polling 
better in the sleeping loop.) It is possible I got this completely wrong 
mind you. I was just going by what is written in this thread - that the 
problem is the sleeping loop sometimes does not run the COND often 
enough, or enough times.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx