EDIT: There is no longer a reason to test sysbench. Random number generation doesn’t seem to be impacted. I was literally getting the same numbers in terms of performance. I’m downloading GeekBench right now.
Now, before anyone gets on me for wanting to test something so insecure this is for an AP Statistics experiment. I want cumulative results that actually prove the performance impact that this patch has on current workloads.
Obviously, there have been microcode updates and everything of that sort to mitigate Meltdown and Spectre–I am only interested in the impact that KPTI has on CPU performance.
To disable PTI:
- Wait for the grub menu during startup or hold shift to access it
- Press “e” on your boot option
- Look for the line starting with “linux” and at the very end add “pti=off” to the command line options
You can also add “nopti” to GRUB_CMDLINE_LINUX in /etc/default/grub and then regenerate Grub as per your distribution, but as far as I know this is distro dependent. The only one I know for certain that works with that option is Fedora.
The tools I’d like to use for these purposes are sysbench and GeekBench. The Phronix Test Suite will be excluded as the only data that may be useful would be from Jack the Ripper and their provided GZIP test, however the differences may not be as prevalent under less stressful loads. Mprime would be very interesting, but I don’t know how I could manipulate the data that it provides to do any justice.
For sysbench, run:
sysbench --test=cpu --cpu-max-prime=20000 --num-threads=12 run
Make sure you set “–num-threads” equal to the number of threads your computer has. For instance, my 5820k with hyperthreading would use 12 and a Ryzen 7 2700X would have 16.
Now, on to GeekBench…
To install it:
- Run “wget http://cdn.geekbench.com/Geekbench-4.3.1-Linux.tar.gz”
- Followed by “tar -zxvf Geekbench-4.3.1-Linux.tar.gz”
- And “cd Geekbench-4.3.1-Linux”
- From there it’s as easy as “./geekbench_x86_64”
You’ll get a link that posts online results. For Arch and Manjaro users, 4.3.1 is available in the AUR.
These tests need to be ran 5 times a piece so that the results can be averaged as there are several factors that can contribute to the given workload. The single core and multi-core scores in GB are what I am most interested in (for obvious reasons).
MAKE SURE THESE ARE RAN BEFORE AND AFTER APPLYING THE COMMAND LINE PATCH (sorry for the caps).
Hardware differences in these tests shouldn’t matter. The primary component I am concerned with the difference in performance calculated as a percent.
As thanks and appreciation, I will publish all of my findings and documentation in a Wiki on GitHub along with proper credit for every user here that decides to contribute :).
I will provide my results shortly. I have system update atm and slow WiFi. Might take a while.
Here is some robust documentation on how kernel page table isolation works: