CPU Usage Differences After Applying Meltdown Patch at Epic Games

Post by ckocagil » Sat, Jan 06, 2018, 1:41 PM UTC

alfanick wrote: post #80

_wmd wrote: post #47

Earlier quoted context omitted.

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);

Or use userspace networking stack (with cards which allow this) to reduce number of syscalls.

Post by Darthy » Sat, Jan 06, 2018, 1:44 PM UTC

progval wrote: post #82

Darthy wrote: post #71

The 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?

It makes sense if you don't want a remote code execution in one of your app to provide a full root shell.

Post by pqh » Sat, Jan 06, 2018, 1:55 PM UTC

imjasonmiller wrote: post #32

dannyw wrote: post #3

Surprise, 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?

Post by jacquesm » Sat, Jan 06, 2018, 2:01 PM UTC

_wmd wrote: post #95

jacquesm wrote: post #69

Earlier 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.

I'd have presumed otherwise, but I'm not sure if you're understanding the API correctly.. it's not about sending multiple messages to the same destination, but to multiple destinations in a single call. The msg_hdr struct has room for specifying the target address. From userspace' perspective, even if the same data isn't being broadcast at every client, just building up a big array (perhaps while looping over the inp…

Post by dogma1138 » Sat, Jan 06, 2018, 2:04 PM UTC

contrarian_ wrote: post #57

_wmd wrote: post #47

Earlier quoted context omitted.

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);

Yep, I was actually debating whether I'd mention sendmmsg/recvmmsg in my original post but I left it out. Definitely an option for UDP, but you're out of luck if your game server uses TCP (surprisingly many do) because you have to recv from each socket separately.