I’d encourage anyway seeing super huge hits to make sure they are not using paravirt (particularly on Amazon). As that needs mitigation the the virt level the impact seems very large.
[deleted]
CPU Usage Differences After Applying Meltdown Patch at Epic Games
261–270 of 296 posts
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#262The Meltdown attack requires an attacker to have a piece of code executed on your server. Epic's servers are used for login, where people send you data, and for game logic, where people also just send you data like "player x moved his avatar here, player y shoots etc". If all the server does is execute the code which Epic wrote themselves and already trust, why would it need to apply the Meltdown patch?
This is a horrible approach to security. If you only secure against attacks you expect, you're gonna have a bad time.
On the other hand, if you aren't affected by what a successful attacker can do, you're in a good place.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#263Thought I'd share our graph too: https://www.jitbit.com/alexblog/270-cpu-usage-stats-after-pa...
Seeing almost 40% increase in CPU load
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#264Earlier quoted context omitted.
Replying here, since the other post I replied to disappeared: Despite the avalanche of downvotes burying my posts, not even one person can actually answer the question I asked: The poster could have simply stopped typing after "Thank you for the explanation". He chose to unnecessarily add something more. So, for everyone who disagrees with me: if what he said wasn't itself "snarky", what was it?
> if what he said wasn't itself "snarky", what was it? A complaint that Hacker News is a less agreeable place than it used to be. Whether that's true or not, don't you think you might find a more effective way of counter-arguing than by being as disagreeable as you can possibly manage without outright swearing in your responses? I get that you're sure that you're right. That's great! That's a source of strong motivat…
I just threw up into my mouth a little.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#265Earlier quoted context omitted.
All of them on HVM.
IIRC, XEN said that 32bit HVM VMs are not affected by Meltdown, and so probably don't get impacted by AWS' patches. They still require Linux kernel updates to protect the kernel space, so changes might still be seen there.
They are affected but there is no fix yet.
64-bit PV is unaffected and won't suffer a performance penalty (more precisely, it was already suffering it!!!), hence my original question, but a 64-bit PV guest can use Meltdown to attack the hypervisor. The fix is to update Xen, though I am not sure if fixes are already publicly available.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#266Earlier quoted context omitted.
Hopefully not. Lawsuits are a fine way to stifle innovation. Imagine how hard it would be to push through any idea at Intel. No one saw this coming. Things happen. It's impossible to predict every contingency. They acted in good faith. Also, heh, users are funny: "all other games i have work fin by the way so there must be a problem whit fortnite."
> Things happen. It's impossible to predict every contingency. Normally I'd agree but not in this case. Notice that besides latest ARM it seems no other architecture is susceptible to Meltdown - s390x, SPARC, POWER, AMD etc. Speculatively loading and executing code across protection boundary is something someone should have thought twice about. Doesn't mean other vendors knew or had PoC examples, but they could have…
According to their patch notes Apple's ARM cores are also vulnerable. And it's not just the latest ARM, the A15, A57, and A72 are vulnerable to a less severe variant of Meltdown.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#267Earlier quoted context omitted.
That only works if messages are independent of answers received and are all known at the same point in time. In most games this typically would not be the case, you'd use a message to cram as much state change into it as is known to keep the game moving fluidly. Packing more than one such message together would serve no purpose.
It's pretty common for FPS server game loops to read all the network packets, update player state, run one tick of game logic and physics for all users in a single game, and then send out updates to everyone.
Server side, yes. Client side, not so much.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#268If it's helpful, Our Node.js, MongoDB, Python servers all with significant network traffic didn't have any measurable impact after KPTI patches on Amazon Linux on T2.medium(burst), M4.large, T2.large(burst) respectively. Our impact is lesser than the figures suggested by redhat's advisory - https://access.redhat.com/articles/3307751
We're using KVM on OpenStack. We use a number of the services and PostgreSQL is our main database platform with our main backend platform being C++ based.
I have performance trending going back 1 year and honestly other than Postgres, the performance #s are like rounding errors. PostgreSQL is getting about a 7% hit on our databases that don't fit in memory.
We also run SAP and again we're not seeing anything. The SAP Database runs on POWER Servers, so obviously unaffected at least by Meltdown.
In our case, there was a major kernel version change, so we're just at the tail end of QC before I can release things to production to begin the rolling restarts tomorrow morning.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#269Thought I'd share our graph too: https://www.jitbit.com/alexblog/270-cpu-usage-stats-after-pa... Seeing almost 40% increase in CPU load
Do you mean 40 percentage points? In other words, tripling?
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#270Earlier quoted context omitted.
That's still not answering many questions. I hope they publish a full analysis at some point.
Since they're using default provisioned EC2 instances, it's likely that the developers don't necessarily even fully understand their performance degradation. They just expect the service that they pay for to work properly.
It's true, but it's not what I meant. They wrote "after a host was patched". This is ambiguous. So they mean the host as in instance, or host as in AWS host machine? Did they just reboot it get on the new/updated VM host, or did they rebuild to include the PTI fixes as well. Did they upgrade anything, or did everything else stay on the same version.