8 ms·
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
by anonacct37 9y ago
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?
- thinkMOAR 9y agoHmm i was wondering about the performance hit, and i kind of miss performance details in the report as i consider it to be significant to report.
- blattimwind 9y ago"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/ https://lwn.net/Articles/738975/ Though the patches evolved since then. So I guess we'll see.
- tscs37 9y agoI 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.
- my123 9y agoEven with PCID, the hit is 29% in a tight syscall loop, but is a complete disaster above 50% with PCID off...
- BeeOnRope 9y agoIn 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).
- bonzini 9y agoPCIDs avoid the TLB invalidation.
- BeeOnRope 9y agoYup, I think so. In that case (PCID hardware on a PCID-enabled kernel), the performance effect should be more limited to the syscall itself. That said, why is the hit still so big with PCID? Surely just the CR3-swap by itself shouldn't be so slow?
- bonzini 9y agoMOV-to-CR3 is pretty slow, yes. In the ballpark of a hundred clock cycles, and you have to do 2 of them. The cost of a system call was about 1000 cycles, maybe less on newer processors---both OSes and processors optimize the hell out of SYSCALL/SYSRET.
- walterbell 9y agoWhich 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 http://lkml.iu.edu/hypermail/linux/kernel/1504.3/02961.html
- Freaky 9y agoPCID's been around for a long time - even my old Westmere Xeons have it. INVPCID is more recent.
- kzrdude 9y agoThe 50% figure is from a benchmark that didn't run on an Intel CPU!
- kpcyrd 9y ago- /* Assume for now that ALL x86 CPUs are insecure */ Before this patch the mitigation was active for all vendors.
- jandrese 9y agoI 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.
- mtanski 9y agoIt sounds like databases on very fast storage will be updated. Tons of syscalls made for disk io and network io.
- lmm 9y agoDatabases are already written to minimise syscalls, like any other heavily performance-tuned system.
- amadvance 9y agoApplications that already put an effort to minimize syscalls are the ones that most likely depend on syscalls performance.
- lmm 9y agoUnlikely. 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.
- tankenmate 9y agoSome portable / embedded databases come to mind. Also "normal" databases doing replication initiation, and replication re-sync. And lastly backup, restore, tar, etc with small files. For files under a handful of pages long mmap() isn't a big gain. Another syscall I think that might cause issues is gettimeofday(), that particular call has been optimised to the nth degree, and lots of user programs spam the crap out of it (mostly necessarily), especially networking and streaming programs. It would be interesting to see how much of an overhead percentagewise page table isolation will cost, and its effects on low end media devices, et al.
- tankenmate 9y agoThe text as written only seeks to defend AMD's product. Whether the sub text goes further is open to non objective speculation. Having said that I'm sure AMD are feeling pretty happy with their statement. Schadenfreude may be too long a bow...
- rurban 9y agoWhat are you talking about? Every other single CPU vendor with an MMD, arm, s390, Sparc, ... either has a separate page translation table register for kernel and user space, or like AMD memory page capabilities, just Intel not. It's very clear who is at fault here.
- amluto 9y agoNot ARM. You're confusing kernel mode with kernel addresses.
- rurban 9y agoNope, read the paper, read the patches. Only Intel is affected. Arm has two such registers, TTB0 and TTB1. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0333h/I1029222.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
- amluto 9y agoI think you're still misunderstanding. The CPU picks TTBR0 or TTBR1 based on the top significant bit of the VA, irrespective of whether the access was initiated by user or kernel code. This is in contrast to s390, which has separate page tables for user mode and kernel mode. I personally much prefer s390's model. And yes, I've read quite a few papers, and I wrote a good fraction of the patches.
- rurban 9y agoOh, thanks. My fault then. I haven't read the arm patches, only the summary.
- SolarNet 9y agoYes. AMD didn't take shortcuts, and implemented the spec correctly. Intel took shortcuts, introduced bugs, and now to compensate for that the OS has to work around it in software, it's going to be slow. For years Intel has reaped the benefits of shortcuts for performance, while AMD has been implementing things correctly; now there is a correction. That's how the market works.
- amluto 9y agoAMD doesn't exactly do an amazing job of avoiding gotchas in their CPUs. They have a bizarre idea of what writing zero to a segment register should do (resulting in info leaks that were only recently fixed on Linux), their demented leaky IRET is even more demented than Intel's, and their SYSRET's handling of SS is downright nutty. OTOH, Intel's SYSRET is actively dangerous and has resulted in severe security holes, and Intel doesn't appear to acknowledge that their design is a mistake or that it should be fixed.
- tfcata 9y agoCan you post a few links maybe to the SYSRET issue mentioned? Just curious.
- amluto 9y agoSYSRET on Intel will fault with #GP if the kernel tries to go to a noncanonical user RIP. The #GP comes from kernel mode but with the user RSP. Before SMAP, this was an easy root if it happened. With SMAP, it's still pretty bad. AMD CPUs instead allow SYSRET to succeed and send #PF afterwards, which is very safe. AMD CPUs are differently dumb. If SYSRET is issued while SS=0, then the SS register ends up in a bogus state in which it appears to contain the correct value but 32-bit stack access fails. Search the Linux kernel for "SYSRET_SS_ATTRS" for the workaround.
- cesarb 9y agoI believe it's this one: https://blog.xenproject.org/2012/06/13/the-intel-sysret-privilege-escalation/ https://blog.xenproject.org/2012/06/13/the-intel-sysret-priv...