> I did manage to pull out an old Lenovo ThinkPad W510 with an Intel Core i7 720QM Clarksfield that is from 2009 and lacks PCID but is affected by this cpu_insecure issue.
> On that old Clarksfield-era ThinkPad I wasn't going to be surprised if the performance was disastrous, but it wound up being better than I had anticipated given all the ongoing drama... In general purpose workloads there was no reportable performance difference in our frequent benchmark test cases. Under I/O, the PTI-using kernel did yield some slower results but not by the margins seen on the newer systems with faster storage. The laptop consumer-grade HDD in this laptop appeared to be the main bottleneck and kernel inefficiencies weren't causing as dramatic slowdowns.
> To some surprise, when carrying out network benchmarks with netperf/iperf3, in at least those contexts PTI didn't have a noticeable impact on the network throughput performance.
Can anyone confirm that the way to identify if a linux system has pcid support is to check /proc/cpuinfo? Or is that merely to identify if the hw supports it, independent of the kernel support?
I checked two ubuntu servers, one 14.04, the other 16.04, both have it. Which seems odd given the claim that it's only been added recently to the kernel.
Also I see nothing showing up in dmesg, no config option and no proc interface on any system.
It seems to be a double win for bare metal machines. They always have PCID and they're less at risk in the first place since they don't share the hardware.
ASID is not an instruction. It's basically an attribute in how MMU tables are set up. Processes usually get different ASIDs from each other and all their MMU pages are tagged with it.
I don't think it's a feature that's binned off. Intel used to bin off virtualization support (which PCID is technically part off), but they added PCID after they stopped binning on virtualization support.
efuses typically have a final efuse to be blown in manufacturing to prevent any further modification of the entire block. Otherwise there's way too high a risk of some broken code accidentally changing the configuration.
You still have to switch the page tables via the CR3 register. It costs.
And the code around there is more complicated now and has more conditionals ... as they say, it'll be opimized over time, this was the fastest reasonable solution they could put in there (and it still took some time).
Also keep in mind that the reason PCID wasn't used by Linux until 4.14 is that the most obvious way of using it incurred more overhead managing the IDs than it saved by not flushing the TLB between different userland processes. This is the land of fiddly details where theory and practice collide and theory often loses in practice.
with PCID, you only flush the kernel mappings out of the TLB (as user mappings are the same). Without PCID you can only flush TLB or not, so you do, and thus user mappings are gone too and need to be repopulated.
I hate that you can't even view Google groups without an account. It also requires us to do nothing but show text. To me groups and blogger has always represented what a terrible web application is.
God I hate Google Groups. I actually need some info from some of those groups and because of account b0rkage and shenanigans it is just too much of a hassle. Weren't they originally Usenet groups or something? Initially they were being decent Web stewards of them (_that_ was a long time ago) but then they got subsumed into the corp. as all things must. It's as inevitable as night follows day. Utter shame.
Many people said that if your processor support PCID, the performance will not be reduced a lot by the new patches. However, after installing new updates for windows and for my very new CPU 7600U everything becomes extremely slow. My laptop is now literally unusable. Even the simplest tasks are very slow. Before this update I was able to watch youtube videos in 4K, now I'm struggling even to watch 480p... I will never buy Intel processors again. In the last few months I only hear lies from Intel regarding Meltdown, Management Engine and other "holes" in their products. Now I can throw my super expensive laptop in garbage. Thank you Intel.
[+] [-] brendangregg|8 years ago|reply
[+] [-] snaky|8 years ago|reply
> On that old Clarksfield-era ThinkPad I wasn't going to be surprised if the performance was disastrous, but it wound up being better than I had anticipated given all the ongoing drama... In general purpose workloads there was no reportable performance difference in our frequent benchmark test cases. Under I/O, the PTI-using kernel did yield some slower results but not by the margins seen on the newer systems with faster storage. The laptop consumer-grade HDD in this laptop appeared to be the main bottleneck and kernel inefficiencies weren't causing as dramatic slowdowns.
> To some surprise, when carrying out network benchmarks with netperf/iperf3, in at least those contexts PTI didn't have a noticeable impact on the network throughput performance.
https://www.phoronix.com/scan.php?page=article&item=linux-mo...
[+] [-] hannob|8 years ago|reply
I checked two ubuntu servers, one 14.04, the other 16.04, both have it. Which seems odd given the claim that it's only been added recently to the kernel.
Also I see nothing showing up in dmesg, no config option and no proc interface on any system.
[+] [-] ajross|8 years ago|reply
[+] [-] pkaye|8 years ago|reply
[+] [-] MBCook|8 years ago|reply
[+] [-] raattgift|8 years ago|reply
In reverse order:
This file goes back several OS versions:
https://github.com/apple/darwin-xnu/blob/master/osfmk/x86_64...
(cf. xnu/osfmk/i386/cpuid.[hc], ibid.)[+] [-] the8472|8 years ago|reply
Virtualbox seems to lack PCID too.
[+] [-] MBCook|8 years ago|reply
[+] [-] tveita|8 years ago|reply
The main performance numbers I've seen so far are from two kinds of sources:
1. Local benchmarks like the Phoronix benchmarks, which I think are all on physical hardware with PCID.
2. Reports from cloud customers like https://forums.aws.amazon.com/thread.jspa?threadID=269858 and https://twitter.com/chanian/status/949457156071288833. These are with a patched host, but with an unpatched guest OS. The best case scenario here seems to be that it doesn't degrade much further when the guest OS is patched.
I don't think I've seen any numbers yet for AWS with a patched guest OS - this would be interesting to see on instances with and without PCID support.
[+] [-] bogomipz|8 years ago|reply
>"The PCID (Processor-Context ID) feature on x86-64 works much like the more generic ASID (Address Space IDs)"
Is ASID the RISC instruction that accomplishes the same thing that PCID does on x86 then?
[+] [-] puzzle|8 years ago|reply
[+] [-] dannyw|8 years ago|reply
[+] [-] monocasa|8 years ago|reply
[+] [-] loeg|8 years ago|reply
[+] [-] pgeorgi|8 years ago|reply
[+] [-] earenndil|8 years ago|reply
[+] [-] Szpadel|8 years ago|reply
[+] [-] KerrickStaley|8 years ago|reply
Why is there still a (smaller) performance hit from the KPTI patch when PCID is used?
[+] [-] ploxiln|8 years ago|reply
And the code around there is more complicated now and has more conditionals ... as they say, it'll be opimized over time, this was the fastest reasonable solution they could put in there (and it still took some time).
Also keep in mind that the reason PCID wasn't used by Linux until 4.14 is that the most obvious way of using it incurred more overhead managing the IDs than it saved by not flushing the TLB between different userland processes. This is the land of fiddly details where theory and practice collide and theory often loses in practice.
[+] [-] dmitrygr|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] yuhong|8 years ago|reply
[+] [-] jimktrains2|8 years ago|reply
[+] [-] neonate|8 years ago|reply
[+] [-] dingo_bat|8 years ago|reply
[+] [-] igravious|8 years ago|reply
[+] [-] dmm|8 years ago|reply
[+] [-] aceoflzlz|8 years ago|reply
[+] [-] davidf18|8 years ago|reply
[deleted]
[+] [-] unitboolean|8 years ago|reply
[+] [-] MBCook|8 years ago|reply