Announcement

Collapse
No announcement yet.

Con Kolivas Fixes Up GUI-Related Stalls In Mesa

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

  • Con Kolivas Fixes Up GUI-Related Stalls In Mesa

    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?pag...-Fixed-Kolivas

  • #2
    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?
    Last edited by Veto; 05-08-2020, 09:14 AM.

    Comment


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

      Comment


      • #4
        Respect for Mr Kolivas.

        Comment


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

          Comment


          • #6
            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?
            Straight from the man page:

            Code:
            SCHED_BATCH: Scheduling batch processes
            (Since Linux 2.6.16.) SCHED_BATCH can be used only at static priorÔÇÉ
            ity 0. This policy is similar to SCHED_OTHER 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.
            Last edited by bug77; 05-08-2020, 11:01 AM.

            Comment


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

              Comment


              • #8
                Originally posted by uid313 View Post
                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?

                Comment


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

                  Comment


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

                    Comment

                    Working...
                    X