GNOME Mutter Switches To High Priority KMS Thread To Avoid Crashes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67377

    GNOME Mutter Switches To High Priority KMS Thread To Avoid Crashes

    Phoronix: GNOME Mutter Switches To High Priority KMS Thread To Avoid Crashes

    The GNOME Mutter compositor has switched its KMS thread priority from a real-time value over to high priority to workaround a situation where the GNOME Shell / Mutter could crash or see its process killed...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • woddy
    Senior Member
    • Feb 2023
    • 281

    #2
    ...ok so even GNOME had a series of bugs...no, because it seemed that only Plasma had bugs!

    Comment

    • bug77
      Senior Member
      • Dec 2009
      • 6523

      #3
      I had a good laugh looking at the comments in that ticket. Whoever wrote them did not know stddev is meaningless if your distribution isn't normal.

      Comment

      • jabl
        Senior Member
        • Nov 2011
        • 650

        #4
        Originally posted by bug77 View Post
        I had a good laugh looking at the comments in that ticket. Whoever wrote them did not know stddev is meaningless if your distribution isn't normal.
        Indeed, they should have used https://en.wikipedia.org/wiki/Median_absolute_deviation

        Comment

        • varikonniemi
          Senior Member
          • Jan 2012
          • 1102

          #5
          so the compositor is so bad that it gets killed as it's responsiveness does not meet realtime requirements?

          Comment

          • Topolino
            Phoronix Member
            • Jun 2024
            • 116

            #6
            Originally posted by woddy View Post
            ...ok so even GNOME had a series of bugs...
            All projects have bugs.

            Some projects also have proper bug management, code reviews, CI, testing and deployment and packaging on the larger distributions. This is the case here.

            Comment

            • Mangogeddon
              Junior Member
              • Nov 2021
              • 26

              #7
              Originally posted by varikonniemi View Post
              so the compositor is so bad that it gets killed as it's responsiveness does not meet realtime requirements?
              No, basically the kernel would kill the thread if the system was overloaded because it couldn't maintain the realtime guarantees. It has nothing to do with GNOME itself as that load could be anything.

              Comment

              • varikonniemi
                Senior Member
                • Jan 2012
                • 1102

                #8
                Originally posted by Mangogeddon View Post

                No, basically the kernel would kill the thread if the system was overloaded because it couldn't maintain the realtime guarantees. It has nothing to do with GNOME itself as that load could be anything.
                You don't understand. It would not be killed if every piece of work was split up in manageable portions. It's only when a RT marked task spends too much time doing something it gets killed. As it's assumed to have malfuntioned as it was supposed to be RT.

                Comment

                • ahrs
                  Senior Member
                  • Apr 2021
                  • 586

                  #9
                  Originally posted by Mangogeddon View Post

                  No, basically the kernel would kill the thread if the system was overloaded because it couldn't maintain the realtime guarantees. It has nothing to do with GNOME itself as that load could be anything.
                  Isn't this what CGroups were designed to solve? Is there no way to put Mutter in a dedicated group, ensuring that it receives adequate resources and doesn't get starved out by anything else? Or does all of this go out the window when you use RT scheduling? It's far too easy for a make -j$(nproc) to consume all CPU. It's also far too easy for a GPU task to consume all GPU resources. Apart from the driver maintaining a queue there is basically no way to schedule GPU resources as far as I know.

                  Comment

                  • Guest

                    #10
                    Originally posted by ahrs View Post

                    way to schedule GPU resources as far as I know.
                    what is there
                    to plan when you have 3,000 cores on a GPU, for example? any processes will fly by without stopping. They don't even need
                    priorities for processes. it would be possible to build everything correctly and kill the processes would no longer have to. but the core engineers are too limited. They can't look at things differently. therefore, the Linux kernel will always run only on a freaking CPU.​


                    P.S
                    I've said this 100 times, but still, instead of building a system in which processes don't need to be killed, they choose to kill. apparently, at least at this level they satisfy their needs in this.
                    Last edited by Guest; 15 November 2024, 06:28 PM.

                    Comment

                    Working...
                    X