Is there anything that an end user can do to mitigate the performance impact?
Switching to AMD or not upgrading your kernel are the only options I can think of.
Linux page table isolation is not needed on AMD processors
221–230 of 298 posts
Re: Linux page table isolation is not needed on AMD processors
#222Earlier quoted context omitted.
> For a large enterprise, monoculture that works is actually better than diversification. But that's the problem. Nothing works 100% of the time, which is why monoculture is bad. When there is a bug that affects 20% of your systems, you can continue operating at 80% capacity, which at a reasonable level of reserve/redundancy means you're still entirely up. With a monoculture the bug affects everything and you're enti…
> This is why hardware abstraction is a thing. This is the mistake in your argument. Motherboards, CPUs, RAM chips, GPUs are analog and physical objects. For AWS to switch a DC from one mobo to another just to find out that this one draws 5% more power and their standard backup generator can't handle it, which now starts a chain reaction of upgrades is going to incur real world costs. Costs that can't be amortized by…
> Motherboards, CPUs, RAM chips, GPUs are analog and physical objects. For AWS to switch a DC from one mobo to another just to find out that this one draws 5% more power and their standard backup generator can't handle it, which now starts a chain reaction of upgrades is going to incur real world costs. Costs that can't be amortized by writing some code to make the motherboards look the same.
Being physical isn't different. The data center is designed to allow systems that consume up to, for example, 500W. When one consumes 400W and another consumes 420W, they're still fungible. A system that consumes 525W can't be used, but you know that so you don't use those.
> This is basically the A/B testing/one-armed bandit problem. How much do you spend time exploring alternatives vs how much time to you reap the benefits of the fact that all your hardware is exactly the same and best of breed, as based on your testing?
That isn't the relevant problem. Even if you choose monoculture, you still have to pay the cost of weighing your alternatives to decide which single model to use.
The cost of diversity is that the second best model on some metric is 20% worse than the best. But that is also the advantage, because on some other metric it's 20% better. You can use each model for its strength. And since you can't perfectly predict the future, when something unexpected happens you're better able to handle it, because for any given thing that only some systems can do, you will have some systems that can do it.
> These situations simply don't lose enough money to make up for the gains of a monoculture.
Beware survivorship bias. It's easier to find an active monoculture company that has never had a major problem than one that has, because having a major problem in a monoculture often results in bankruptcy.
> Do you/they use five different cloud providers in equal measure to make sure you have diversity if one has an issue?
For services with high availability requirements, people absolutely do that.
> Do you/they use five different software stacks in case there is a remote exploit for RoR and PHP holds things up?
That wouldn't reduce attack surface. The relevant thing people do is to use two factor authentication.
> Do you/they buy groceries at five different grocery stores in case one of them has an e. coli outbreak that the other four don't?
Having multiple local grocery stores is a thing people want. And people do actually use them, because different stores have the best price or quality for different products.
> chances are you've at some point built a RAID array. Did you put different size and performance drives from different manufacturers into it or did you buy N of the same drive type to ensure even performance? If so, why?
These are spec differences, not supplier differences. There is no issue with using drives of the same size and speed from different manufacturers.
Also compare ZFS, which allows you to efficiently use unmatched drives for the same filesystem.
Re: Linux page table isolation is not needed on AMD processors
#223Earlier quoted context omitted.
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…
Google has stated that they would move to the power9 if the performance claimes live up to the hype. That has yet to be seen.
POWER has been better performing than intel since basically 1990, though intel's tick/tock cadence and trading blows in fab tech have kept things interesting. That shouldn't be surprising since POWER is ultra focused on the high end and intel is fending off attacks from the low end and never had good long term thinking on the high end.
The reason every server isn't POWER is: ecosystem. For any random company, switching archs for anything less than a multiple factor gain is a daunting multi-generation proposition. For a hyperscaler like Google the bar is a lot lower but you need a compliant vendor that will do a lot of the long haul platform work. IBM's been trying to establish that for many years and is just about to pull it off. Supply chain is also important, hyperscalers have come to expect buying and building systems a certain way and IBM will now just sell chips or even the IP for you to fab yourself. And of course the total cost calculus: capex, and opex in the form of TDP, support burden.
Google _will_ be using P9 for GPU servers internally. The inflection point for them was I/O and memory bandwidth. So, paradigm shift was what was needed to turn a juggernaut.. and that is what adding a bunch of accelerators to your platform is. Intel has no good solution there.
Re: Linux page table isolation is not needed on AMD processors
#224Earlier quoted context omitted.
It sounds like databases on very fast storage will be updated. Tons of syscalls made for disk io and network io.
Databases are already written to minimise syscalls, like any other heavily performance-tuned system.
Applications that already put an effort to minimize syscalls are the ones that most likely depend on syscalls performance.
Re: Linux page table isolation is not needed on AMD processors
#225Earlier quoted context omitted.
Databases are already written to minimise syscalls, like any other heavily performance-tuned system.
Applications that already put an effort to minimize syscalls are the ones that most likely depend on syscalls performance.
Unlikely. It's relatively easy to get to the point where syscalls aren't the bottleneck by a long margin, so the only apps where syscalls are the bottleneck will be those that haven't put in any optimisation effort.
Re: Linux page table isolation is not needed on AMD processors
#226Is there anything that an end user can do to mitigate the performance impact?
It can be turned off
Re: Linux page table isolation is not needed on AMD processors
#227Earlier quoted context omitted.
No. The check is being made what CPU is underlying before applying the fix.
Not yet. That patch hasn't been merged as of now.
Probably because the method of checking is flawed and should be done in make/model (i'm no kernel expert but this is the general oppinion i've seen so far).
I've seen nothing except the 'caution side lets do it with all' approach and no indication of other problems on the other hand.
Re: Linux page table isolation is not needed on AMD processors
#228Did he know it would blow up in a few weeks? https://www.fool.com/investing/2017/12/19/intels-ceo-just-so...
What's the connection?
Re: Linux page table isolation is not needed on AMD processors
#229All 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...
Short INTC maybe but I am not sure this means that AMD will increase in value over the long run as a result of this one incident.
AMD is doing a lot of things right recently and they have a bright future. And after seeing this, apparently they have been doing things right longer than I thought.
Re: Linux page table isolation is not needed on AMD processors
#230Earlier quoted context omitted.
Don't most of them do that already?
Right now, they just own you and your data. With this, they will own your machine.
Pretty extraordinary that a user's most important files (their documents and whatever else is in their home folder) are accessible to any app at any time. Why are we still using this outdated security model? On Windows, I could download an .exe and it could upload the entire contents of my Dropbox without even prompting for elevation or anything. Kinda scary when you think about it.