PCID is now a critical performance/security feature on x86
archive.is
archive.is
> 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...
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.
In reverse order:
This file goes back several OS versions:
https://github.com/apple/darwin-xnu/blob/master/osfmk/x86_64...
sysctl machdep.cpu.features | grep PCID
Virtualbox seems to lack PCID too.
$ cat /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx rdrand hypervisor lahf_lm abm pti avx2
bugs : cpu_insecure
$ uname -a
Linux archvm 4.14.11-1-ARCH #1 SMP PREEMPT Wed Jan 3 07:02:42 UTC 2018 x86_64 GNU/Linux
$ lspci
00:04.0 System peripheral: InnoTek Systemberatung GmbH VirtualBox Guest ServiceIt looks like Ubuntu 18 Bionic Beaver may have it. (4.15) I suppose some folks use Ubuntu in a datacenter, but more likely the LTS releases and 18 is not likely in many production datacenters.
Can you confirm that Redhat backported that newer PCID code into the 3.10 kernel branch? If so, people should not be seeing a performance hit on the KPTI patch.
Curiously enough, FreeBSD has had PCID support since 2013 (r255060). We found it improved performance in microbenchmarks:
> In the microbenchmarks, using the PCID decreased latency of the context switches by ~30% on SandyBridge class desktop CPUs, measured with the lat_ctx program from lmbench.
> If available, use INVPCID instruction when a TLB entry in non-current address space needs to be invalidated. The instruction is typically available on the Haswell.
It appears the first PCID code was merged in 4.14.12 so you will probably have that in the coming days / weeks. CoreOS is also 4.14.11.
For those on LTS releases, we may have to venture into uncharted waters. The first that came to mind was elrepo.org, as they apply some of the same build options that Redhat uses against the latest upstream. Their kernel packages are meant to provide support for newer laptop hardware...
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.
>"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?
On 32bit systems, the address space is divided into 16 segments of 256MB each. Each of them has a privileged register that can be setup in different ways (e.g. half could be per-process, half machine-wide). The 4 bits from the segment ID eventually map to a 24 bit value (or trigger a protection violation if e.g. the page is kernel-only), so that the original 32bit address becomes a 32 - 4 + 24 = 52 bit virtual address. The MMU, then will look up the higher order bits in the address to convert from 52bit virtual addresses to actual 32bit physical addresses. The virtual address space is larger because in theory you could have processes with completely disjoint addressing (up to 1 million of 4GB each, i.e. 4PB). In the end, you still only have 32 bits to address memory chips, though. :-)
On 64 bit systems, there are many more segments, 236. Instead of having (64 * billion) registers, there is a single register pointing to a hash table in memory that the CPU will walk through. Addresses are translated from 64->80->64 bits in a similar way.
Why is there still a (smaller) performance hit from the KPTI patch when PCID is used?
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.
I don't like obscuring the original domain but agree that Google Groups URLs posted to HN have consistently been annoying.
As an example, I wanted to do some research on early language features of Python (e.g. around 1993). The info is in Usenet postings of that time, surely present in Google Groups years ago. Now, I can't find anything useful. A advanced search using dates doesn't return anything. Their user interface is horribly bad compared to what it used to be.
Another example: I did some research on Deep Blue and Deep Thought, after reading Crazy Bird's book. With the old Google Groups, I could follow the discussion of the Deep Blue tournament, in chronological order. There was all sorts of interesting things like computer chess programmers speculating on how Deep Blue worked and people posting analysis of chess positions. All that is now gone or at least not searchable.
So sad that all of this knowledge has apparently disappeared. There was loads of information shared on Usenet and the storage space required to preserve it would be trivial.
How it should work following a “build your first web app” tutorial:
1. User opens page
2. You detect an old login cookie and discretely ask if they want to login
3. If they do so, you see the previous page with more UI (e.g. subscribe, reply, etc.)
How it works now:
1. Users opens page
2. Instead of looking at the content they wanted to see, the user is automatically redirected over to a login page with a mandatory full two-factor check even if you've recently logged in to other Google properties
3. After completing that process, you're dumped on the groups.google.com homepage 4. Since there were a bunch of redirects, you have to know how to use your browser's history to go back 3-4 pages because simply hitting back will just redirect you to the homepage again.