Originally posted by bug77
View Post
Announcement
Collapse
No announcement yet.
Con Kolivas Fixes Up GUI-Related Stalls In Mesa
Collapse
X
-
Does anyone know if the threads in question need to be reniced in the first place? This seems like the common case of the developer thinking the operating system is more dumb than it really is. What Con is doing here is simply adjusting the code so it does what the developers probably intended.
I bet the right decision here is to remove the renicing of the thread entirely or to give the thread a light nudge, like a nice of +5 rather than +19 and an entirely different scheduler policy, and let the scheduler figure this out.
And in some ways, this reminds me of the guy who was porting games to Stadia and was using a spin lock instead of using a mechanism that made the scheduler comprehend the locking dependencies.Last edited by damentz; 08 May 2020, 06:53 PM.
- Likes 2
Comment
-
Originally posted by Veto View PostGreat 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?
Originally posted by Ernst SjöstrandYou mention GUI stalls and at the same time latency insensitive... which one is it?Originally posted by Con KolivasThe use of the UTIL_QUEUE_INIT_USE_MINIMUM_PRIORITY flag for threads internally is for threads deemed to be latency insensitive and low priority. The use of nice and SCHED_BATCH together fulfil this criteria meaning these threads may wait for hundreds of milliseconds before receiving CPU time under load. The issue is that with SCHED_IDLE they may wait many seconds and even up to a minute under conditions of load and eventually can lead to resource starvation/conflict that affects other latency sensitive threads.Last edited by Hi-Angel; 08 May 2020, 06:58 PM.
- Likes 5
Comment
-
Originally posted by pal666 View Postthat's why people invented double blind method
Plus Michael is constantly posting articles about this or that Mesa enhancement- this way I can get them long before my Distro pushes them in.
Comment
-
Originally posted by Hi-Angel View PostYou may find a similar question was asked on the original MR.
Originally posted by Hi-Angel View PostHe basically says that while the idea of assigning low priorities to workloads of, well, low priorities, is nice and dandy, but it was implemented a bit wrong. Specifically, using SCHED_IDLE was overkill, in certain situations that could lead to starvation of such threads. He instead replaced that with SCHED_BATCH. That achieves the same thing, but wouldn't lead to starvation under high load.
Being pessimistic, I would say the patch may not really fix the problem, but just makes it less visible. But what do I know...
Comment
Comment