Quoting Chris Wilson (2019-01-29 17:02:00) > After noticing that we trigger preemption events for currently executing > requests, as well as requests that complete before the preemption and > attempting to suppress those preemption events, it is wise to not > consider the queue_priority to be authoritative. As we only track the > maximum priority seen between dequeue passes, if the maximum priority > request is no longer available for dequeuing (it completed or is even > executing on another engine), we have no knowledge of the previous > queue_priority as it would require us to keep a full history of enqueued > requests -- but we already have that history in the priolists! > > Rename the queue_priority to queue_priority_hint so that we do not > confuse it as being exactly the maximum priority in the queue, but merely > an indication that we have seen a new maximum priority value and as such > we should check whether it should preempt the currently running request. > > v2: s/preempt_priority_hint/queue_priority_hint/ as preempt implies it > being only used for the singular task of preemption and not the wider > question of waking up due to a change in the queue. > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> Twas, Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
