5 ms·

Can someone who is more familiar with Meltdown speculate on this? Is this a quick fix and is it likely to be optimised over time and become less slow? Or is thi

by davej 9y ago

Can someone who is more familiar with Meltdown speculate on this? Is this a quick fix and is it likely to be optimised over time and become less slow? Or is this the raw trade-off and current hardware will always suffer slow-downs to this degree. Can an OS be rearchitected in ways that would mitigate the performance loss?

PeterisP 9y ago
It's a hardware issue, IMHO it'll be reversed after we get structurally re-engineered (i.e. a new generation, which takes a lot of time to get through all the pipeline from design to actual manufacturing) of CPUs, everything Intel manufactures in 2018 and possibly even 2019 will likely still have those issues.
nuand 9y ago
The "fix" Intel pushed out this week is a microcode update that in my experience doesn't fix or address Meltdown at all. The update does however make Spectre slightly less reliable, so I'm going to assume that the microcode update has something to do with fixing, updating, or adding new controls to the branch predictor buffer. So absent a microcode update that outright fixes Meltdown, there will always be some level of slow-down for vulnerable devices. System calls now jump from user mode code to a stub kernel in "supervisor memory". The stub kernel then does a full context switch (touching %cr3 paging register and wiping a good portion of the TLB), and once the real kernel finishes, it does a full context switch back to the stub kernel. It's all terribly inefficient, and realistically it's unlikely that there will only be negligible performance impacts. It should also be noted that this "work-around" doesn't fix processor, it just makes it so that that there's nothing juicy in the supervisor memory. You may have to learn to live with this for a while. Even if it takes Intel a month to design and validate a fix for Meltdown, prototype and mass production turn around times mean that no customer will have a processor that isn't vulnerable to Meltdown until April-June 2019.
deleted 9y ago
[deleted]
jsheard 9y ago
> Can an OS be rearchitected in ways that would mitigate the performance loss? The performance loss comes from extra overhead on syscalls, so it could be sidestepped by allowing programs to do more work per syscall. At its simplest that could mean adding more syscalls that perform the same operation over an arbitrarily long list of inputs (like linux's sendmmsg) but I would like to see kernels take inspiration from modern graphics APIs that allow arbitrarily long lists of arbitrary operations to be batched and executed with a single syscall. GPUs had this stuff figured out years ago.
- sanxiyn 9y ago
  Note that Red Hat patented batching syscalls... https://www.google.com/patents/US9038075 https://www.google.com/patents/US9038075
  - bch 9y ago
    1) this is exciting, if not also brilliant 2) SQL transactions as prior art? If they’re successful w their patent, I sure hope there’s a way for BSDs to try it on.
    - pkaye 9y ago
      RedHat has a patent promise that they will not enforce their patents against any free software that make use of their patents. https://www.redhat.com/en/about/patent-promise https://www.redhat.com/en/about/patent-promise
- rphlx 9y ago
  I agree with your basic point - a generic syscall batching mechanism would be a good thing - but it's worth noting that GPU workloads are usually much better suited for ginormous "fire and forget" command/command+data sequences. syscalls tend to be more interactive/round-trip-dependent, where syscall N+1 is at least partially determined by a userspace process doing something fairly complicated with the result of syscall N. This is a natural enemy of massive batching.

by davej 9y ago

PeterisP 9y ago

It's a hardware issue, IMHO it'll be reversed after we get structurally re-engineered (i.e. a new generation, which takes a lot of time to get through all the pipeline from design to actual manufacturing) of CPUs, everything Intel manufactures in 2018 and possibly even 2019 will likely still have those issues.

nuand 9y ago

The "fix" Intel pushed out this week is a microcode update that in my experience doesn't fix or address Meltdown at all. The update does however make Spectre slightly less reliable, so I'm going to assume that the microcode update has something to do with fixing, updating, or adding new controls to the branch predictor buffer. So absent a microcode update that outright fixes Meltdown, there will always be some level of slow-down for vulnerable devices. System calls now jump from user mode code to a stub kernel in "supervisor memory". The stub kernel then does a full context switch (touching %cr3 paging register and wiping a good portion of the TLB), and once the real kernel finishes, it does a full context switch back to the stub kernel. It's all terribly inefficient, and realistically it's unlikely that there will only be negligible performance impacts. It should also be noted that this "work-around" doesn't fix processor, it just makes it so that that there's nothing juicy in the supervisor memory. You may have to learn to live with this for a while. Even if it takes Intel a month to design and validate a fix for Meltdown, prototype and mass production turn around times mean that no customer will have a processor that isn't vulnerable to Meltdown until April-June 2019.

deleted 9y ago

[deleted]

jsheard 9y ago

> Can an OS be rearchitected in ways that would mitigate the performance loss? The performance loss comes from extra overhead on syscalls, so it could be sidestepped by allowing programs to do more work per syscall. At its simplest that could mean adding more syscalls that perform the same operation over an arbitrarily long list of inputs (like linux's sendmmsg) but I would like to see kernels take inspiration from modern graphics APIs that allow arbitrarily long lists of arbitrary operations to be batched and executed with a single syscall. GPUs had this stuff figured out years ago.

sanxiyn 9y ago
Note that Red Hat patented batching syscalls... https://www.google.com/patents/US9038075 https://www.google.com/patents/US9038075
- bch 9y ago
  1) this is exciting, if not also brilliant 2) SQL transactions as prior art? If they’re successful w their patent, I sure hope there’s a way for BSDs to try it on.
  - pkaye 9y ago
    RedHat has a patent promise that they will not enforce their patents against any free software that make use of their patents. https://www.redhat.com/en/about/patent-promise https://www.redhat.com/en/about/patent-promise
rphlx 9y ago
I agree with your basic point - a generic syscall batching mechanism would be a good thing - but it's worth noting that GPU workloads are usually much better suited for ginormous "fire and forget" command/command+data sequences. syscalls tend to be more interactive/round-trip-dependent, where syscall N+1 is at least partially determined by a userspace process doing something fairly complicated with the result of syscall N. This is a natural enemy of massive batching.