On 09/01/2025 14:12, Christian König wrote:
Am 09.01.25 um 14:27 schrieb Tvrtko Ursulin:
[SNIP]
@@ -259,7 +258,7 @@ struct drm_sched_rq {
spinlock_t lock;
/* Following members are protected by the @lock: */
- struct drm_sched_entity *current_entity;
+ ktime_t rr_deadline;
struct list_head entities;
If I'm not completely mistaken you can now also nuke this entities
list if you haven't already removed all users.
I had a version which did that too. But then I dropped it in favour of
only keeping entities with queued jobs in the tree. (Before both the
list and the tree contained entities which submitted at least one job
in the past.)
I kind of like keeping the tree trimmed (would it lower the rb tree
re-balancing costs?) in which case the full list is needed for that
karma processing business.
Well, is anybody still using this karma stuff (maybe amdgpu, but we
could drop that)? That as well turned out to be a quite broken approach.
Git grep says etnaviv, lima, panfrost, v3d.
Basically the idea behind karma was that on a crash you re-submit the
same job over and over again until it either doesn't crash any more or
your karma became to bad.
Well I don't know, TBD I guess. In any case probably best to leave that
work for a different series to keep this one reasonably focused.
I also still like the idea of keeping the tree pruned of idle entities
so for me rq->entities list is not a big deal.
And when you now think of what Einstein once said about insanity then
yeah that was also my first thought when I learned about that :)
Right, resubmitting hanging jobs sounds highly questionable indeed.
But it is also the entity->guilty business.
Now if entities were reference counted... ;) The list walk
hack/workaround in drm_sched_increase_karma could also go away.
Regards,
Tvrtko
Regards,
Tvrtko
Regards,
Christian.
struct rb_root_cached rb_tree_root;
};
