[PATCH v4 3/3] randomize_kstack: Unify random source across arches
Ryan Roberts
ryan.roberts at arm.com
Tue Mar 3 06:43:04 PST 2026
On 22/02/2026 21:34, Thomas Gleixner wrote:
> On Mon, Jan 19 2026 at 13:01, Ryan Roberts wrote:
>> I tested an earlier version of this change on x86 bare metal and it
>> showed a smaller but still significant improvement. The bare metal
>> system wasn't available this time around so testing was done in a VM
>> instance. I'm guessing the cost of rdtsc is higher for VMs.
>
> No it's not, unless the hypervisor traps RDTSC, which would be insane as
> that would cause massive regressions all over the place.
>
> So guessing is not really helpful if you want to argue performance.
Sorry for the slow response. I no longer have access to a recent bare metal x86
system that I can do performance testing on. All I have is the Sapphire Rapids
(m7i.24xlarge) VM.
My original testing was on bare metal Sapphire Rapids (same number of CPUs and
RAM as the VM).
Just to be clear, these are the results I got with bare metal vs vm. Negative is
an improvement (less time). (I)/(R) means statistically significant
improvement/regression:
+-----------------+--------------+---------------+---------------+
| Benchmark | Result Class | x86_64 | x86_64 |
| | | bare metal | VM |
+=================+==============+===============+===============+
| syscall/getpid | mean (ns) | (I) -7.69% | (I) -17.65% |
| | p99 (ns) | 4.14% | (I) -24.41% |
| | p99.9 (ns) | 2.68% | (I) -28.52% |
+-----------------+--------------+---------------+---------------+
| syscall/getppid | mean (ns) | (I) -5.98% | (I) -19.24% |
| | p99 (ns) | -3.11% | (I) -25.03% |
| | p99.9 (ns) | (R) 9.84% | (I) -28.17% |
+-----------------+--------------+---------------+---------------+
| syscall/invalid | mean (ns) | (I) -6.94% | (I) -18.56% |
| | p99 (ns) | (I) -5.57% | (I) -20.06% |
| | p99.9 (ns) | (R) 10.53% | (I) -25.04% |
+-----------------+--------------+---------------+---------------+
So both sets of results represent an improvement, I would say.
Given the level of review that the series has had, I propose to repost today,
then hopefully Kees will be happy to put it in his branch so that it can get
plenty of linux-next soak testing and if there are any x86 regressions lurking,
hopefully ZeroDay will spot them?
Thanks,
Ryan
>
> Thanks,
>
> tglx
More information about the linux-riscv
mailing list