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

91–100 of 298 posts

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

#91

Post by walterbell »

tscs37 wrote: post #22
blattimwind wrote: post #4

Earlier quoted context omitted.

"The overhead was measured to be 0.28% according to KAISER's original authors,[2] but roughly 5% for most workloads by a Linux developer.[1]" [1] = https://lwn.net/Articles/738975/ Though the patches evolved since then. So I guess we'll see.

I believe the 0.28% are only for CPUs that support PCID. Earlier CPUs (which is a lot still) will get a much harder hit since you'll have to flush the entire TLB.

Which Intel CPUs support PCID? Based on this Linus message, it was introduced in 2015, so Broadwell and later?

http://lkml.iu.edu/hypermail/linux/kernel/1504.3/02961.html

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

#92

Post by BeeOnRope »

my123 wrote: post #25
tscs37 wrote: post #22

Earlier quoted context omitted.

I believe the 0.28% are only for CPUs that support PCID. Earlier CPUs (which is a lot still) will get a much harder hit since you'll have to flush the entire TLB.

Even with PCID, the hit is 29% in a tight syscall loop, but is a complete disaster above 50% with PCID off...

In fact, the tight syscall loop isn't even necessarily the worst case: the primary cost of this change isn't the a direct cost in the syscall, but the CR3 switch which invalidates the TLB and incurs an ongoing cost for some time following the syscall.

The worse case would be something like a frequent syscall followed by code that touches a number of distinct cache lines, which all now require a TLB reload and page-walk (even here the cost is tricky to evaluate since there are various levels where the paging structures can be cached beyond the TLB, so the cost of a page-walk various a lot depending on locality of the paging structures used).

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

#94

Post by kevin_thibedeau »

airesQ wrote: post #38

Given Intel's dominance of the server market does this mean that datacenter computational capacity will see an overnight ~5% drop? Is there enough spare capacity to cope with this? Will spot-instance prices go up? Will I need more instances of a given type to run the same workload?

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.

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

#95

Post by uhhhhhhh »

IgorPartola wrote: post #67
dboreham wrote: post #53

Earlier quoted context omitted.

I think it will because it shows the downside of a monoculture. Hence big purchasers of CPUs will want to diversify. Also good for ARM vendors I suppose. Disclosure : bought AMD this morning before headlines saying "Buy AMD, short INTC" appeared.

Has there ever been a precedent for this? When there were major bugs in Intel CPU's (or drives, or RAM, or motherboards) did the likes of Amazon and Google invest in diversification? And has it affected stock prices meaningfully? My guess is that they'll see this as just another one off issue that can be fixed with software, then move on. For a large enterprise, monoculture that works is actually better than diversif…

When you're building out your DC, its a function of cost relative to performance/power use. I could see new setups may look at AMD over Intel, especially if they're running workloads impacted by the software fix, at least for the current generation of CPU's, maybe even the next 1-2 that are in the pipeline.

When you're scaling up/maintaining your DC, you're much more likely to be looking for single sku, like for like products that allow similar tooling, knowledge base, experience etc... Like you said, monoculture has its benefits in some situations.

Personally even with this bug I'd be very hesitant to switch. Our previous tests between them for very specific workloads showed our best cost/performance was with Intel over successive generations, and the scaling/tip over points were different. We have a combination of experience and knowledge around the existing arch and how our applications and workloads interact with it that involved a number of pain points that I'm not sure its worth it to re-experience with another arch.

On the other hand, those running on non-bare metal, cloud based, auto-scaling/automated solutions that have a wider tolerance for individual app performance, are probably in a situation where they care less about this, but at the same time have little to no say in the arch they run on, that decision is left to the cloud providers they use.

just my 2 cents anyways.

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

#96

Post by cjbprime »

ac29 wrote: post #90
zer00eyz wrote: post #82

I have to wonder: Can intel release a drop in CPU that will avoid or mitigate this issue? The infrastructure investment in intel cores is huge, if a drop in replacement lets me minimize downtime, re-gain performance and is "cost effective" compared to a cost prohibitive replacement does this result in intel having a sales INCREASE where it replaces bad silicon? I don't know enough about this issue to speak to the iss…

Until more information is available, who knows. It might be fixable in microcode, it might be fixable in a new processor stepping, it might require a deeper rework that wont come out until the next generation of processors (or even the generation after that).

Though if it were going to be fixed in microcode, it seems like this would have played out by Intel just having released new microcode already and encouraged people to update to it, rather than every OS vendor scrambling to rewrite large chunks of their memory management, you know?

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

#97

Post by uhhhhhhh »

IgorPartola wrote: post #79
zanny wrote: post #74

Earlier quoted context omitted.

Do you really think enough people care about the ME / control of hardware in general / hardware that spies on you or is out of your control to influence the stock price of a company the size of Intel?

No. That's exactly what I'm saying. Most people don't care. Enterprise users do care because ME is useful for them. It's a feature, not a nefarious backdoor that the NSA made Intel include under the cover of darkness. They'll see this as a small problem that should be fixed and will ask Intel to do so. Intel will fix it, most everyone will move on. I don't think ME will take down Intel stock, and neither will this pa…

If my recollection serves, when Intel had what was the largest/most expensive recall in the world in the 90's (at that time anyways), their stock still nearly doubled that year.

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

#98

Post by rst »

pkaye wrote: post #93

Is this issue only of concern for Intel with Linux? What about OSX, BSD or Windows?

Reports are that Windows is also getting an update for this; see refs to recent NT kernels here: http://pythonsweetness.tumblr.com/post/169166980422/the-myst...

and the original source for that report: https://twitter.com/aionescu/status/930412525111296000

OSX and BSD variants are an interesting question...

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

#100

Post by unethical_ban »

brians wrote: post #52
rrdharan wrote: post #16

Earlier quoted context omitted.

I'm curious what you are referring to re: the DLC concept? Did you mean this thing? https://en.wikipedia.org/wiki/Intel_Upgrade_Service Seems like that was discontinued a long time ago (2011) so was wondering if there was something more recent that happened?

IIRC, this fall’s i9 chips and the motherboards supporting them have software-unlockable features. You can literally buy more PCI lanes. Which is another way of saying you had those lanes, and Intel wanted more money before letting you use what you’d already bought.

AMD's triple core processors were quads with disabled cores. Often times processors within a line are processors with manually set lower clock multipliers or disabled cache.

Sounds like Intel has just made it unlockable instead of permanent. It just brings to the fore what was already being done, and makes us question again the ethics of pricing models.

Post reply on HN