Re: [REGRESSION] drm/sched: FAIR policy causes serious performance degradation at max GPU load on 9070XT

[Tvrtko Ursulin]

On 12/08/2026 12:58, Philipp Stanner wrote:
> On Wed, 2026-08-12 at 12:37 +0100, Tvrtko Ursulin wrote:
> > Jokes aside, I agree with the above analysis that a better fix would be
> > to pull things under the lock, and interestingly, Philipp had a lock
> > widening patch not so long ago but I don't remember what happened it or
> > how exactly did it look. It would possibly have fixed this problem.
>
> https://lore.kernel.org/dri-devel/a0d969408a5a55dfb6d0b3e65906fd7bbf3eee1c.camel@xxxxxxxxxxx/
>
> TBH I got discouraged and increasingly dissatisfied with the state of
> our community, because whenever I try to fix things that are
> *obviously* broken and incorrect (and which were usually not broken by
> me), with relatively simple patches, I have to work uphill and only
> receive pushback.
>
> Reviewers and supporters are usually absent unless they want to have
> more features or performance-hacks added, though it is apparent that
> many indeed read what we are doing.
>
> Should things get better it's usually not acknowledged, and should
> things go wrong one runs danger of getting blamed with hindsight-bias.
>
> Had my patch landed and (speculatively) prevented this regression, no
> one would have noticed, but Phoronix would write some nice article
> about the FPS gain in video games, achieved by Tvrtko Ursulin :)

Not sure if you are calling me out here or not, since apart from a 
direct mention, the lore link above is also a reply to my email, so for 
the record, I did give my ack for those patches. Plus I spent time 
testing them. So if you were in fact calling me out, I don't see how 
that is warranted. And on the wider topic I also never shied away from 
the non-glamorous work.

Going back to your linked patch series, now that I re-read it and 
reminded myself, it wouldn't have solved the regression from this thread 
since it left drm_sched_rq_pop_entity() outside the lock. But I did 
agree even then it was a step in the right direction. So if you respin 
it (last patch seemed buggy according to sashiko), maybe replace with my 
version of the completion removal (what happened with that one?), 
ideally fold the patch which removes the double re-lock cycle into the 
actual locking change (I think that's better), my ack still stands.

But I also still think ack from AMD is needed as well since the changed 
code paths are by large used from amdgpu.

Regards,

Tvrtko
> Ah well.
>
> My vision for drm_sched has been that we absolutely need to start
> establishing strict computer science standards and have to prioritze
> formal correctness, simplicity and documentation over features and
> *especially* performance.
>
> Though I maybe should have tried to be more polite and diplomatic about
> it, the evidence that I see is that the DRM community does not actually
> want the above. At least I have to conclude that from the lack of
> encouraging participation and the presence of discouragement.
>
> So if I want to add a spinlock for something obviously broken, the
> burden of proof is on me, not on the one who broke it. If I want to
> prevent someone from adding a 4th drm_sched_start_x() function for
> performance-reasons, then I receive not-so-nice emails.
>
> Folks here seem to want to continue like they did for the last 15
> years.
>
> If anyone here reads this who *doesn't* want to continue like we did
> for the last 15 years, then I would kindly ask for public participation
> and help with moving things towards the right direction. Simple emails
> with "I support this idea, +1", would almost be enough.
>
>
> It would seem that these recent event might proof that I was right
> about our fundamental issues.
>
>
> P.