On 29/01/2019 11:21, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-29 11:15:35)
On 29/01/2019 08:58, Chris Wilson wrote:
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
How can it go higher? Only because I915_PRIORITY_NEWCLIENT is higher
than I915_PRIORITY_WAIT? In that case would re-ordering those help? I
don't remember if there was a reason for the current order.
Yes. There's more reasons later (media-bench is quite insistent about
this ;).
You were quite adamant in insisting that WAIT be the most minor of
boosts :)
I was afraid that might have been the case. :) So we are firmly into
tweaking the scheduler for particulars clients territory.. and that
before we even have time-slicing!
In my mind it probably still makes sense that WAIT is lowest bump.
How about a we add a new smallest internal dedicated level for preempted
contexts? Because I don't like how this patch would intermingle with
either WAIT or NEWCLIENT.
#define I915_PRIORITY_PREEMPTED ((u8)BIT(0)) /* Must be lowest */
#define I915_PRIORITY_WAIT ((u8)BIT(1))
#define I915_PRIORITY_NEWCLIENT ((u8)BIT(2))
?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
