Announcement

Collapse
No announcement yet.

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

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

  • ryao
    replied
    Originally posted by NotMine999 View Post

    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 ocumented 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.
    As a non-mainline kernel developer myself, I would not accuse the mainline developers of not caring about the performance of their code. If anything, they care so much that they have done things developers of other platforms would regard to be insane:
    • Mutex unlocking has subtly different semantics from the userland counterpart that causes bugs if the developers using them are unaware of the differences. This is done just for the sake of a tiny bit more performance. This is a reference to how unlocking a mutex will continue accessing memory to process the waiter list just to let a thread in the fast lock path execute sooner.
    • Ticketed spinlocks were invented to reduce SMP contention on NUMA systems. This one is not insane, but the idea that anyone would try to sequeeze out extra performance from a fundamental locking mechanism that nobody thought could be made better is just mind boggling.
    • RCU has been used everywhere to improve concurrency, including in certain trees (which is a pain to understand)
    • Efforts have been made to eliminate locking in favor of the absolute minimal memory barriers necessary to make things work as fast as they can openness on the DEC Alpha (which has the most relaxed barrier model there is) have been made.
    • CPU prefetch has been overused to the point of harming performance in some cases, such as in linked list traversal.
    • Compiler hints in the form of likely and unlikely are peppered throughout the code. This could turn into hints for the CPU branch predictor depending on the architecture, or can just result in ordering things differently so that the branch predictor is inclined to predict a certain way. It is an extremely esoteric form of optimization.
    • Various tiny accessor/setter functions have been made into preprocessor definitions to forcibly inline them to avoid function call overhead. It is possible to program without using such functions, but it makes things more maintainable. Doing it the way the kernel has done it gives you the best of both worlds, but makes debugging more difficult as you cannot instrument processor definitions.
    • container_of was implemented to allow certain structures that extend other structures to be implemented in a way that avoids a single pointer. The way that this is implemented uses typeof, which is a compiler extension that is incompatible with the C standard.
    • plenty of kernel config options have remarks about slight slowdowns or small increases in memory usage.
    • skbufs are incredibly ugly, but they reduce pointer indirections to increase network performance.
    • kernel virtual memory has been crippled to ensure that it is not used very much for the sake of slightly faster execution.
    • direct reclaim has been implemented to make memory allocations complete sooner under low memory situations (although this is debatable).
    • they implemented an ugly hack called ->bmap so that swap files are as performant as swap devices. This is not compatible with anything that is not an in place filesystem and the value of it is questionable, but that is a tangent for another thread.
    • they adopted a few hacks from IRIX to speed up performance in certain things. Namely, the non-standardized (and poorly defined) O_DIRECT and short extended attributes (that allow storage in inodes to avoid an extra disk access or two).
    Those are just off the top of my head. If you look at the FreeBSD or Illumos source code, you would see that most of these techniques are not done, or are done extremely sparingly. The extent to which the Linux kernel has been overoptimized in certain instances is extreme. On other platforms, the developers are far more conservative at doing things and only make changes when profiling shows a tangible improvement. If a micro-optimization can be shown to make a tiny improvement, the mainline developers will often do it.

    Of course, there are areas where you will see that not much effort is given (like /dev/urandom until recently), but overall, the Linux kernel’s mainline developers do more for performance than those of just about any other platform. In some benchmarks comparing platforms, the differences show themselves quite prominently.

    Leave a comment:


  • dungeon
    replied
    Originally posted by NotMine999 View Post
    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
    Last edited by dungeon; 17 November 2018, 07:21 PM.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by birdie View Post
    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.
    Last edited by NotMine999; 18 November 2018, 01:32 PM. Reason: fix a typo

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by creative View Post
    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.

    Leave a comment:


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

    Originally posted by oooverclocker View Post
    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.
    Last edited by dungeon; 17 November 2018, 06:35 PM.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by creative View Post
    schmidtbag Windows is fine. Been gaming on it for the past three weeks straight.
    sarcasm?

    Leave a comment:


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

    Leave a comment:


  • Azrael5
    replied
    Originally posted by tuxd3v View Post

    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?

    Leave a comment:


  • tuxd3v
    replied
    Originally posted by Azrael5 View Post
    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..

    Leave a comment:


  • birdie
    replied
    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!

    Leave a comment:

Working...
X