On 04/11/2026 11:04, Philipp Stanner wrote:
On Wed, 2026-11-04 at 10:43 +0000, Tvrtko Ursulin wrote:
On 04/11/2026 08:48, Philipp Stanner wrote:
On Wed, 2026-11-04 at 08:33 +0000, Tvrtko Ursulin wrote:
I lost you here - what should the comment say?
Just a "TODO: entity->rq_priority could not be fully removed due to the
partial revert of the CFS scheduling rework. For formal correctness, it
still has to be adjusted here".
Just so that the reader sees that this is in an intermediate state
right now, and so he's incentivized to git-blame the TODO to find the
associated commits and mailing-list-archives.
I would rather not do it in a patch with a Fixes: tag, or actually at
all - it feels arbitrary to sprinkle a TODO mentioning future work at a
single random place like set_priority(). Could we go with these two as
they are and continue from there?
Help me out here, I don't have the CFS series paged into my mind right
now:
Will future callers, after your redesign, make use of
drm_sched_entity_set_priority()?
Yes it stays, as does entity->priority. It's just that with FAIR
priority affects the virtual runtime accounting and all entities are in
a single run queue.
Three step plan would be like this:
1.
With these two fixes we think about making FAIR the default (all known
bugs sorted).
2.
Then, if it works fine for a kernel release or two, we can remove FIFO
and RR.
3.
Then, after another release or two we can reapply the final part of the
original series - replace multiple run-queues with a singleton embedded
into the scheduler.
2 & 3 could happen together, but lets say a regression is discovered
between 2 and 3 and there is no other way than bringing back FIFO/RR
then it is easier if 3 hasn't landed yet since that's the part with
touches all the drivers (due drm_sched_init_args).
Regards,
Tvrtko
