Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 4, 2024 14:09 UTC (Tue) by pizza (subscriber, #46)
In reply to: Opt Green: KDE Eco's New Sustainable Software Project by pizza
Parent article: Opt Green: KDE Eco's New Sustainable Software Project

> Even at the OS level, these "mitigations" generally consist of completely disabling hardware features, usually with _severe_ performance impacts. If said features can even be disabled at all.
> Whereas with these microcode patches, the OS has the option of using considerably higher-performance mitigations, if anything is needed at all.

Just wanted to follow up on this -- If you have to disable SMT to mitigate against a vulnerability, that's going to result in about a 33% performance impact, meaning you'll need roughly 50% more resources [1] to achieve the same overall performance. 50% more servers, 50% more datacenter space, 50% more power (and cooling), etc.

Or you can use a combination of microcode patches (possibly in combination with OS awareness) to bring the net performance hit to ~5%. It's a win-win for everyone. [2]

[1] Assuming SMT gives you a 50% performance boost on average, losing it means your net performance will be approximately 2/3rds of what it was with SMT. (SMT gains are highly workload dependent)
[2] If you run truly private/trusted workloads, you're going to disable all of these mitigations as part of your performance tuning anyway.

Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 4, 2024 14:18 UTC (Tue) by adobriyan (subscriber, #30858) [Link]

> [1] Assuming SMT gives you a 50% performance boost on average, losing it means your net performance will be approximately 2/3rds of what it was with SMT. (SMT gains are highly workload dependent)

Kernel compile is only ~10% faster with HT.

Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 4, 2024 15:16 UTC (Tue) by farnz (subscriber, #17727) [Link]

A 50% performance boost for SMT would be very surprising on a well-designed core. 5% to 20% is a more normal range for an Out of Order Execution (OoOE) design, since a good OoOE design is set up so that one thread can utilize all of the resources available, and your workload will tend towards bottlenecking on the same resource for all threads (with SMT's performance boost coming from the fact that you hit the bottleneck at different points on different hardware threads).

Opt Green: KDE Eco's New Sustainable Software Project

Posted Jun 4, 2024 19:35 UTC (Tue) by cesarb (subscriber, #6266) [Link]

> Just wanted to follow up on this -- If you have to disable SMT to mitigate against a vulnerability, that's going to result in about a 33% performance impact, meaning you'll need roughly 50% more resources [1] to achieve the same overall performance. 50% more servers, 50% more datacenter space, 50% more power (and cooling), etc.

Most servers aren't running untrusted code, and so far I have heard of no demonstration of speculative execution vulnerabilities being exploited solely through a network connection. The impact on web browsers (which do run untrusted code) is lower, since client computers are idle most of the time and thus have resources to spare; there might be an impact on power use, but there's a difference between "the battery lasts less time" and "hopelessly insecure".