Con Kolivas Fixes Up GUI-Related Stalls In Mesa

[phoronix]

Phoronix: Con Kolivas Fixes Up GUI-Related Stalls In Mesa

Con Kolivas known for his longtime work on improving Linux desktop responsiveness with largely working on the kernel and the likes of MuQSS has now seen his first Mesa patch merged for fixing unexpected GUI-related stalls...

http://www.phoronix.com/scan.php?page=news_item&px=Mesa-GUI-Stalls-Fixed-Kolivas

[Veto]

Great to see Con making some real upstream improvements - again!

From the patch:

SCHED_IDLE on linux can lead to extraordinarily long periods of no scheduling leading to starvation of minimum priority threads for such an extended period that it can eventually lead to GUI stalls. Switch to renicing the threads to the lowest priority and use the SCHED_BATCH scheduling policy which is a hint to the scheduler that this is latency insensitive thread instead. This change has been confirmed to address unexpected GUI related stalls in mesa applications across a range of different linux kernels.

I wonder though, how threads that can lead to GUI stalls can be classified as "latency insensitive"? It seems like the real fix would be to boost priority, when the result of the thread is soon needed and before the stall occurs. Hopefully someone can provide some insight?

[uid313]

Oh, and the guy is also a doctor who helped to design COVID-19 equipment.

[siyia]

Respect for Mr Kolivas.

[mitch074]

If I'm not mistaken, his patch is indeed increasing priority by making the thread switch from 'run at idle only' to 'run with lowest NICE level' witch is actually above idle only.

[bug77]

Great to see Con making some real upstream improvements - again!

From the patch:


I wonder though, how threads that can lead to GUI stalls can be classified as "latency insensitive"? It seems like the real fix would be to boost priority, when the result of the thread is soon needed and before the stall occurs. Hopefully someone can provide some insight?

Straight from the man page:

[B]SCHED_BATCH: Scheduling batch processes[/B]
(Since Linux 2.6.16.) [B]SCHED_BATCH [/B]can be used only at static prior‐
ity 0. This policy is similar to [B]SCHED_OTHER [/B]in that it schedules
the thread according to its dynamic priority (based on the nice value).
The difference is that this policy will cause the scheduler to always
assume that the thread is CPU-intensive. Consequently, the scheduler
will apply a small scheduling penalty with respect to wakeup behavior,
so that this thread is mildly disfavored in scheduling decisions. This
policy is useful for workloads that are noninteractive, but do not want
to lower their nice value, and for workloads that want a deterministic
scheduling policy without interactivity causing extra preemptions
(between the workload's tasks).

So it doesn't have much to do with latency per se, but rather deterministic scheduling.

[yoshi314]

where are those stalls noticeable? i never noticed an issue, unless it's more visible on his scheduler?

[tsuru]

Oh, and the guy is also a doctor who helped to design COVID-19 equipment.

This is mainly speculation but maybe they are related. Could this have been discovered while working on an interface for his device?

[mitch074]

No, he's just really big on smooth GUI stuff. His work on kernel schedulers is well known, I'm not surprised he'd look into Mesa if he found that, even with his own patched kernel, his UI would freeze.

[evil_core]

micheal : I think it would be interesting to benchmark this change in games (min and avg FPS and input lag)