Best summary I've found for the somewhat technical but not hardware-or-low-level-hacker reader is arstechnica. https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...
Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
361–370 of 567 posts
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#362If you look here: https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheit... (Sorry it is German) But if you scroll down to "Windows-Benchmarks: Anwendungen" you can see that most applications do not have any performance hit with the Windows patch. Only M.2 SSD seem to be affected.
It is possible Microsoft has mitigated the issue in a way that has much lesser performance impact. Maybe they had a highly tuned feature to enable kernel page separation already coded but disabled. I won't be surprised if even the Linux implementation is tuned to the absolute limit in the coming months.
I think so too. It also seems the Linux version right now is in a "get it to work, optimize later" state.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#363Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#364Earlier quoted context omitted.
It's a good thing CPU is fairly compressible. Unless you meter it very carefully, you'll see the performance hit and it'll not impact you that much. Very few of my physical boxes are over 70% CPU utilization on a daily average. It's, however, really bad if you sell CPU cycles for a living. You just lost between 5 and 30% of your capacity. If you have a large building, you just lost part of your parking lot to the Int…
Their competitors are also affected. Also a 30% decrease is also equivalent to setting Moore's law back 7 months. A 5% loss is only setting it back 1 month. I know that's a bit of a naive calculation. But the point is computing power has long operated in an exponential domain. So big differences in absolute numbers aren't necessarily a big deal.
According to this patch comment, AMD x86 chips are not affected: https://lkml.org/lkml/2017/12/27/2
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#365Is it just me or was this post's title changed?
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#366Earlier quoted context omitted.
We're still learning, but it looks like pgbench is 7% to 15% off: https://www.postgresql.org/message-id/20180102222354.qikjmf7...
I've seen that message. It acknowledges the same problems: do-nothing problems over a local unix socket. Real-world use cases introduce much more latency from other sources in the first place. I'm sticking with an expectation in the 2%-5% range.
Yep, this is getting blown way out of proportion by all of these tiny scripts that just sit around connecting to themselves. Even pgbench is theoretical and intended for tuning; you're not going to hit your max tps in your Real Code that is doing Real Work.
In the real world, where code is doing real things besides just entering/exiting itself all day, I think it's going to be a stretch to see even a 5% performance impact, let alone 10%.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#367Earlier quoted context omitted.
Presumably, for a certain important class of application, CPU is not used "densely", i.e. continually. Instead it's used intermittently, like a gas rather than a solid... Hence compressibility. Such applications are far from being CPU-bound, in other words.
So a cloud provider would be an example. Compressible similar to a sparse file I guess as well. Thanks this makes sense.
I think it was meant that a normal application does not utilise the CPU all the time, which can be seen by looking at the task manager CPU usage % = X. Any extra processing needed to fix this bug will have to come out of the remaining 100-X%. This is OK as long as you have enough spare %, and can afford the extra power usage for that processing.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#368Earlier quoted context omitted.
It's a good thing CPU is fairly compressible. Unless you meter it very carefully, you'll see the performance hit and it'll not impact you that much. Very few of my physical boxes are over 70% CPU utilization on a daily average. It's, however, really bad if you sell CPU cycles for a living. You just lost between 5 and 30% of your capacity. If you have a large building, you just lost part of your parking lot to the Int…
Problem is, most companies that need a lot of power only care about one thing - peak performance. And they tune it carefully in order to not overspend while guaranteeing minimal downtime. This means that they'll have to pretty much scale their infrastructure up by exactly 30%. That's a LOT for these big clients. Honestly, I'd just make sure the server firewalls are super tight and not take in the future patches. At l…
If they really care about peak performance, I don't believe the PTI patch will affect them. If you can change your system in a way that the power-hungry part does not work on untrusted data, you can not with "nopti" and ignore it. Systems which both need lots of maxed-out CPUs and traffic directly from wild internet are pretty rare. They're unlikely to run on a virtualised systems either.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#369Earlier quoted context omitted.
I've seen that message. It acknowledges the same problems: do-nothing problems over a local unix socket. Real-world use cases introduce much more latency from other sources in the first place. I'm sticking with an expectation in the 2%-5% range.
Yep, this is getting blown way out of proportion by all of these tiny scripts that just sit around connecting to themselves. Even pgbench is theoretical and intended for tuning; you're not going to hit your max tps in your Real Code that is doing Real Work. In the real world, where code is doing real things besides just entering/exiting itself all day, I think it's going to be a stretch to see even a 5% performance i…
I think 5% is a reasonable guess for a database. Even a well-designed database does have to do a lot of IO, both network and disk. It's just not a "fixable" thing.
But overall, yeah.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#370Earlier quoted context omitted.
As I mentioned in the other thread yesterday database and database like applications are going to be hit particular hard. Even more so on fast flash storage. Double whammy compared to apps just doing network IO. And while databases try to minimize the number of syscalls they still end up doing a lot of them for read, writeout, flush.
How would you trade this knowledge? Intel has already dropped and AMD is up. Maybe there's more to move, but first-order effects are at least partially priced in already. But what about second-order effects? Seems like virtualization should be vulnerable (VMWare and Citrix), but maybe they actually benefit as customers add more capacity. Software-defined networking and cloud databases should also suffer though it's u…
Possibility: a cloud vendor who mostly-uses-AMD, versus one that mostly-uses-Intel, just got handed a massive price/performance relative advantage.