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

[phoronix]

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?page=news_item&px=Linux-5.2-Turning-On-GCC9-LP

[Peter Fodrek]

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/

[M@GOid]

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.

[Michael]

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.

[Guest]

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.

[xorbe]

Do not want!

[MaxToTheMax]

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.

[MaxToTheMax]

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.

[Guest]

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.

[MaxToTheMax]

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.