CPU Usage Differences After Applying Meltdown Patch at Epic Games
71–80 of 296 posts
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#72I know they don't have to share the details, but the "patched" part is not really clear. Did they update to a new image / more recent kernel / anything else? Much like the redis post linked in HN before, we don't know if the impact is because of the "pti turned off/on" change, or are there more moving parts involved.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#73Surprise, surprise, Intel’s Meltdown patch has significant and serious performance impacts for specific kinds of workloads. All because Intel decided to “optimise” by checking for permissions after speculative retirement, instead of before like AMD.
If, as you say, AMD is not affected by Meltdown unlike Intel, will this significantly change the server market? Excuse the pun, but would this make e.g. AMD EPYC a lot more attractive for such data centers?
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#74Surprise, surprise, Intel’s Meltdown patch has significant and serious performance impacts for specific kinds of workloads. All because Intel decided to “optimise” by checking for permissions after speculative retirement, instead of before like AMD.
If, as you say, AMD is not affected by Meltdown unlike Intel, will this significantly change the server market? Excuse the pun, but would this make e.g. AMD EPYC a lot more attractive for such data centers?
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#75The 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?
They're using a "monolithic" cloud provider and don't have a choice in their current deployment?
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#76The 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?
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#77I know they don't have to share the details, but the "patched" part is not really clear. Did they update to a new image / more recent kernel / anything else? Much like the redis post linked in HN before, we don't know if the impact is because of the "pti turned off/on" change, or are there more moving parts involved.
If I recall correctly from older posts (I played Fortnite for a while), they're using AWS.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#78Earlier quoted context omitted.
I wouldn't be so sure of that. They at least run Javascript through their web browser.
The Nintendo Switch generally only allows white-listed pages. So the attack vector is pretty small. The other consoles, yes, should be possible. But I think not too many people use their consoles for browsing.
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#79The 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?
Re: CPU Usage Differences After Applying Meltdown Patch at Epic Games
#80Pretty much what I predicted here: https://news.ycombinator.com/item?id=16054674 > Sounds like servers handling lots of small UDP packets would be hit pretty hard.
There's potential for a little rearchitecting to help, at least in the case of UDP: NAME sendmmsg - send multiple messages on a socket SYNOPSIS #define _GNU_SOURCE /* See feature_test_macros(7) */ #include int sendmmsg(int sockfd, struct mmsghdr *msgvec, unsigned int vlen, unsigned int flags);