Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux page table isolation is not needed on AMD processors

lkml.org

Post reply on HN
Print view View original

161–170 of 298 posts

Re: Linux page table isolation is not needed on AMD processors

#161

Post by zmatt »

contrarian_ wrote: post #75
jandrese wrote: post #6

Earlier quoted context omitted.

I think the du case was an outlier. Normal workloads shouldn't be so heavily affected. I am expecting a few percent loss on most programs though. It's basically a larger penalty for making a syscall, which was already a fairly slow operation so performance minded people avoid them in tight loops. It will be bad for people who need to do lots of fast I/O I suspect.

Sounds like servers handling lots of small UDP packets would be hit pretty hard.

Reduce number of syscalls by using sendmmsg()/recvmmsg() to batch together multiple packets per syscall?

Re: Linux page table isolation is not needed on AMD processors

#163

Post by cma »

lvs wrote: post #154
amckenna wrote: post #150

Earlier quoted context omitted.

Here is some more context - http://pythonsweetness.tumblr.com/post/169166980422/the-myst... The connection between the linked article in this comment and the linked page for this post is that there is a potentially huge bug that will be made public soon and it just affects Intel processors, not AMD - hence the large sale of stock by the Intel CEO.

If your allegation is true, that would seem to be very illegal.

I've heard you can schedule big sales all the time and then regularly cancel them unless something goes wrong. Apparently there is no rule against insider canceling.

Re: Linux page table isolation is not needed on AMD processors

#164

Post by dannyw »

jandrese wrote: post #6
anonacct37 wrote: post #2

This feels like a big FU to Intel. I've heard this patch can slow down programs like du by 50%. Does that mean AMD is going to find itself running twice as fast as competitors?

I think the du case was an outlier. Normal workloads shouldn't be so heavily affected. I am expecting a few percent loss on most programs though. It's basically a larger penalty for making a syscall, which was already a fairly slow operation so performance minded people avoid them in tight loops. It will be bad for people who need to do lots of fast I/O I suspect.

Postgres and Redis are looking at a 20-25% performance hit.

https://www.phoronix.com/scan.php?page=article&item=linux-41...

Re: Linux page table isolation is not needed on AMD processors

#165

Post by kllrnohj »

mehrdadn wrote: post #137
mortehu wrote: post #134

Earlier quoted context omitted.

They are only system calls when you need to wait or wake up processes. https://en.m.wikipedia.org/wiki/Futex

I was assuming contention but I guess I wasn't clear, sorry. I updated the post. But saying this "only" occurs when there is contention is very misleading since it makes it seem like the scenario of lock contention is a negligible concern. It's not.

Thread-suspending contended mutexes are already extremely slow. If you have a heavily-contended mutex you already have a major performance bug. If this is the kick in the pants you need to go fix it that's arguably a good thing ;)

Note that mutex contention does not itself mean immediately falling back to futex - commonly you'll spinloop first and hope that resolves your contention (fast), then fall back to futex (slow)

Re: Linux page table isolation is not needed on AMD processors

#166

Post by kevin_thibedeau »

kentonv wrote: post #144
kevin_thibedeau wrote: post #94

Earlier quoted context omitted.

Given what's been disclosed so far it seems an exploit using rowhammer techniques would be unlikely to work with ECC RAM. Consumer systems will be screwed unless a tolerable microcode update is released.

I don't think this issue is related to rowhammer. I think people have been speculating about rowhammer because it's a famous hardware bug, but none of the details of page table isolation seem to align with a rowhammer-based attack.

This enables the first step in a rowhammer attack: identify the privileged address you want to target.

Re: Linux page table isolation is not needed on AMD processors

#167

Post by boomboomsubban »

IgorPartola wrote: post #119
Sir_Substance wrote: post #108

Earlier quoted context omitted.

>It's a feature, not a nefarious backdoor that the NSA made Intel include under the cover of darkness. Let's be clear: It's both.

Is it? Again, that a big claim to make in five words and drop the mic. Can you cite anything to back it up?

It creates a huge attack vector on most computers that the user has almost no control over. Even if Intel are completely uninvolved, some intelligence agency will try to exploit it.

Re: Linux page table isolation is not needed on AMD processors

#168

Post by 0x00000000 »

bitwind wrote: post #8

All Intel CPU's are affected, mitigation syscall overhead increased by 50%, and none of AMD CPU's affected? I would say this could be an indicator to short INTC and long AMD...

If the hit is as bad as they say (30% performance), cloud providers will be almost forced to upgrade when the new hardware comes out that fixes it. Are they really ready to adopt AMD? Go long on INTC?

Re: Linux page table isolation is not needed on AMD processors

#169

Post by cjcole »

cma wrote: post #163
lvs wrote: post #154

Earlier quoted context omitted.

If your allegation is true, that would seem to be very illegal.

I've heard you can schedule big sales all the time and then regularly cancel them unless something goes wrong. Apparently there is no rule against insider canceling.

Speculative execution bug causes speculative stock sale non-cancellation?

Re: Linux page table isolation is not needed on AMD processors

#170

Post by electic »

This is going to have dramatic effect on the cloud computing market. It might make sense to make sure any VMs you run are on AMD processors or it can really hurt your performance and basically cost you more to do the same workload.

It also seems, from early benchmarks, this can slaughter performance with databases.

Post reply on HN