Announcement

Collapse
No announcement yet.

Linux 5.2 To Enable GCC 9's Live-Patching Option, Affecting Performance In Select Cases

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

  • Linux 5.2 To Enable GCC 9's Live-Patching Option, Affecting Performance In Select Cases

    Phoronix: Linux 5.2 To Enable GCC 9's Live-Patching Option, Affecting Performance In Select Cases

    The GCC 9 compiler is due to be released in the next few weeks and among the many new and improved features is an option designed to help generate binaries that are friendly for live-patching purposes. With the Linux 5.2 kernel, this option will be used by default when building a kernel with live-patching support and that has the potential for some slight slowdowns...

    http://www.phoronix.com/scan.php?pag...ing-On-GCC9-LP

  • #2
    Originally posted by phoronix View Post
    Phoronix: Linux 5.2 To Enable GCC 9's Live-Patching Option, Affecting Performance In Select Cases

    With GCC 9.1.0 being released in late April or early May,
    Performance impact of the option was measured on three different Intel machines - two bigger NUMA boxes and one smaller UMA box. The majority of the tests is unaffected. The only significant exception is the scheduler section which suffers 1-3% degradation.
    http://www.phoronix.com/scan.php?pag...ing-On-GCC9-LP
    Small gift for AMD

    1st May 1969
    AMD Advanced Micro Devices is founded
    http://www.computinghistory.org.uk/d...es-is-founded/

    Comment


    • #3
      If I not mistaken, Canonical offers paid support for live patches. Lets see if they will let this free option on by default in future releases.

      Comment


      • #4
        Originally posted by [email protected] View Post
        If I not mistaken, Canonical offers paid support for live patches. Lets see if they will let this free option on by default in future releases.
        Last check they allowed free support with 1~2 systems if you did a user registration with their system.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #5
          I hope Arch will not enable this by default, as it makes no sense on a workstation that boots in 4 seconds. I don't even bother with suspending my laptop because of how fast it boots up, and losing 3% in scheduling performance (pretty much the only thing a proper (micro)kernel should be doing) is a silly trade off.

          Comment


          • #6
            Do not want!

            Comment


            • #7
              I'm going to offer a counterpoint here: I think this tradeoff is 100% worth it.

              Linux boot times might be pretty fast these days, but boot times are irrelevant because they don't tell the whole story. The true cost of rebooting is the time it takes to get your environment back to where you had it. Maybe you have an ongoing development project, and you have editors open to the relevant files and terminals open to the relevant directories with relevant commands in the history of each. Maybe you have a movie paused that you were going to finish later. Heck, even my browser takes something like half an hour to start due to all the tabs I have open. Realistically, to get everything back to how I had it so I can continue getting work done, rebooting takes about an hour, even though my boot time is only a few seconds. That's why I only do it a few times per year.

              If you are a digital neat-freak who sees his desktop background more often than every three months and never opens more than two tabs at a time, this would be a great time to keep your suggestions to yourself. I bought my computer so I could work the way I want to work.

              Comment


              • #8
                Originally posted by DoMiNeLa10 View Post
                I hope Arch will not enable this by default, as it makes no sense on a workstation that boots in 4 seconds. I don't even bother with suspending my laptop because of how fast it boots up, and losing 3% in scheduling performance (pretty much the only thing a proper (micro)kernel should be doing) is a silly trade off.
                Keep in mind that a benchmark that isolates scheduling performance does not reflect impact on most real-world workloads. Even if you're doing heavy multitasking, only a tiny fraction of a percent of your CPU time is spent executing kernel code. This change multiplies only part of that that tiny fraction of a percent by 1.03.

                If your workload spends a substantial amount of time executing kernel code, and more specifically kernel scheduler code, you probably know who you are.

                Comment


                • #9
                  Originally posted by MaxToTheMax View Post
                  Keep in mind that a benchmark that isolates scheduling performance does not reflect impact on most real-world workloads. Even if you're doing heavy multitasking, only a tiny fraction of a percent of your CPU time is spent executing kernel code. This change multiplies only part of that that tiny fraction of a percent by 1.03.
                  I can't justify wasting CPU cycles on a feature I don't need. Just like how I refuse to run a compositor even though the overhead is neglible, I don't want to take a performance hit for something I'd never use in a given setup. If I were setting up a critical server, the payoff would be there, but in this case it can only be a loss.

                  Comment


                  • #10
                    Originally posted by DoMiNeLa10 View Post

                    I can't justify wasting CPU cycles on a feature I don't need. Just like how I refuse to run a compositor even though the overhead is neglible, I don't want to take a performance hit for something I'd never use in a given setup. If I were setting up a critical server, the payoff would be there, but in this case it can only be a loss.
                    That's valid if you're building your own kernel, but distro maintainers have to think about a wide variety of different use cases.

                    EDIT: also, I see live kernel patching as a basic desktop usability feature, not a server feature. If you have a mission critical server and you don't have a good plan for what to do while it's shut down, you're doing it wrong. Rebooting is far more of a hardship for desktop users than server users.
                    Last edited by MaxToTheMax; 04-09-2019, 04:35 PM.

                    Comment

                    Working...
                    X