The Spectre/Meltdown Performance Impact On Linux 4.20, Decimating Benchmarks With New STIBP Overhead

[creative]

schmidtbag Windows is fine. Been gaming on it for the past three weeks straight.

[birdie]

Meanwhile a request in LKML to enable to disable (sic!) all these mitigations was and met with an utter indifference and now if you want to reach previously available performance you have to peruse a ton of documentation and you also have to recompile the kernel since some mitigations are compiled-in regardless, without a runtime option to disable them.

Well done, kernel devs, well done!

[tuxd3v]

Is there a way to compensate this involution!?

The unique way, would be to buy AMD..or run intel cpus without security, or even, run them with atom processors performance, but cost/consumption of top line processors..

[Azrael5]

The unique way, would be to buy AMD..or run intel cpus without security, or even, run them with atom processors performance, but cost/consumption of top line processors..

AMD processors are immune?

[cde1]

These kind of posts are the reason why I subscribed to Phoronix Premium. Thank you Michael, and keep up the great work!

[NotMine999]

schmidtbag Windows is fine. Been gaming on it for the past three weeks straight.

sarcasm?

[dungeon]

OK, HyperThreading technology is now less hyper, but still does something

This is the biggest disaster for Intel CPUs with HT that I can imagine.

I am only waiting someone to start exposing nVidia Ti cards vulnerabilities, that is the same crap - no one care about security there Or better to say - gamers does not care.

[schmidtbag]

schmidtbag Windows is fine. Been gaming on it for the past three weeks straight.

Well depending on your display, GPU, and graphics settings, a performance loss up to 20% on the CPU might not be noticeable.

[NotMine999]

Meanwhile a request in LKML to enable to disable (sic!) all these mitigations was and met with an utter indifference and now if you want to reach previously available performance you have to peruse a ton of documentation and you also have to recompile the kernel since some mitigations are compiled-in regardless, without a runtime option to disable them.

Well done, kernel devs, well done!

I find it interesting to note that "impact on kernel performance" was not considered/challenged by the person(s) replying to the original poster (Artem) in the thread.

Are Linux kernel developers not concerned with performance impacts of their coding?

I have fragments of memory that suggest that Linus has challenged contributors to justify/document the performance impact of their code, generally when those impacts were claimed to improve performance.

Some mitigations are included in CPU microcode according to Intel. The only way to revert that is to load older microcode.

A few kernel boot flags exist that will turn off some of these features. That is useful for testing and for those not interested in these fixes.

What bothers me is that the replies to the original poster (Artem) seemed to suggest that no kernel boot flags exist in some cases due to the use of GCC compiler flags. What are those flags? have they been clearly documented? I think GCC compiler flags being used to mitigate these security issues need to be clearly documented so those that want to "revert" those specific changes can do so by recompiling the kernel for themselves. Then a user can rebuild their kernel without any security fixes of their own choosing.

Seriously, it sounds to me like the responses in that email thread suggest Linux kernel devs simply accepting that these security fixes will negatively impact Linux kernel performance by taking a "let's not bring up that subject again" approach.

I say that Michael's testing is clearly("blatant" might be a better word) showing the "before & after" impact of these security fixes, especially in Intel processors.

It is times like this exact situation that prove the value of the work that Michael is doing.

Why the Linux Foundation or other large entities involved in Linux kernel development do not provide Michael and Phoronix with an annual grant to help defray his costs incurred in doing all of this performance testing is simply beyond me.

If the corporate world & Linux development communities can get something important like this testing for free, then why should they have to pay to support for it? Sad.

[dungeon]

Are Linux kernel developers not concerned with performance impacts of their coding?

Security goes above performance as performance is something relative

Not just about kernel, but about pretty much anything you have 3 base levels you can think of - secure, optimal or agressive. With less optimizations you are more safe and secure and the opposite

Goal is to be as optimal as possible (or just selective, so where really needed and where you expect an stronger impact), as not many like to run slow total secure crap

On this particular case, well users might like it or not but no doubt they must and should mitigate these, as these are hardware flaws