Announcement

Collapse
No announcement yet.

Con Kolivas Fixes Up GUI-Related Stalls In Mesa

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by bug77 View Post
    So it doesn't have much to do with latency per se, but rather deterministic scheduling.
    Whatever question you answered, it's not the one you quoted.

    Comment


    • #12
      Originally posted by Veto View Post
      Great to see Con making some real upstream improvements - again!
      My thoughts exactly.

      Comment


      • #13
        Originally posted by evil_core View Post
        micheal : I think it would be interesting to benchmark this change in games (min and avg FPS and input lag)
        It really, really wouldn't.

        This patch, as I understand it, increases the priority of processes scheduled as the absolute lowest possible priority. Games do not fall into that category.

        Comment


        • #14
          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.

          Comment


          • #15
            Originally posted by Veto View Post
            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?
            You may find a similar question was asked on the original MR. Quoting:

            Originally posted by Ernst Sjöstrand
            You mention GUI stalls and at the same time latency insensitive... which one is it?
            Originally posted by Con Kolivas
            The 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.
            Understanding Con's reply may require to peek at the patch to see what identifiers were removed/added. He 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.
            Last edited by Hi-Angel; 08 May 2020, 06:58 PM.

            Comment


            • #16
              I just built Mesa just to try this out ... "seems" faster, but I haven't run any formal testing.

              Comment


              • #17
                Originally posted by kcrudup View Post
                I just built Mesa just to try this out ... "seems" faster
                that's why people invented double blind method

                Comment


                • #18
                  Originally posted by kcrudup View Post
                  I just built Mesa just to try this out ... "seems" faster, but I haven't run any formal testing.
                  This is what's called the placebo effect.

                  Comment


                  • #19
                    Originally posted by pal666 View Post
                    that's why people invented double blind method
                    Eh, I looked at the commit; knowing the logic behind the various scheduling priorities prompting the change was good enough justification for me.

                    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


                    • #20
                      Originally posted by Hi-Angel View Post
                      You may find a similar question was asked on the original MR.
                      Thanks! However, he did not really get an answer either...

                      Originally posted by Hi-Angel View Post
                      He 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.
                      Yes, yes, I get the *effect* of the fix. But that still does not answer the *cause* to why "latency insensitive" tasks can cause stalls. Going from scheduling in seconds to hundreds of milliseconds might still not be enough to avoid frame drops, if the work of the tasks at some time becomes critical?!

                      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

                      Working...
                      X