[PATCH v6 00/29] context_tracking,x86: Defer some IPIs until a user->kernel transition
Juri Lelli
juri.lelli at redhat.com
Tue Oct 14 05:58:01 PDT 2025
Hello,
On 10/10/25 17:38, Valentin Schneider wrote:
...
> Performance
> +++++++++++
>
> Tested by measuring the duration of 10M `syscall(SYS_getpid)` calls on
> NOHZ_FULL CPUs, with rteval (hackbench + kernel compilation) running on the
> housekeeping CPUs:
>
> o Xeon E5-2699: base avg 770ns, patched avg 1340ns (74% increase)
> o Xeon E7-8890: base avg 1040ns, patched avg 1320ns (27% increase)
> o Xeon Gold 6248: base avg 270ns, patched avg 273ns (.1% increase)
>
> I don't get that last one, I did spend a ridiculous amount of time making sure
> the flush was being executed, and AFAICT yes, it was. What I take out of this is
> that it can be a pretty massive increase in the entry overhead (for NOHZ_FULL
> CPUs), and that's something I want to hear thoughts on
>
> Noise
> +++++
>
> Xeon E5-2699 system with SMToff, NOHZ_FULL, isolated CPUs.
> RHEL10 userspace.
>
> Workload is using rteval (kernel compilation + hackbench) on housekeeping CPUs
> and a dummy stay-in-userspace loop on the isolated CPUs. The main invocation is:
>
> $ trace-cmd record -e "ipi_send_cpumask" -f "cpumask & CPUS{$ISOL_CPUS}" \
> -e "ipi_send_cpu" -f "cpu & CPUS{$ISOL_CPUS}" \
> rteval --onlyload --loads-cpulist=$HK_CPUS \
> --hackbench-runlowmem=True --duration=$DURATION
>
> This only records IPIs sent to isolated CPUs, so any event there is interference
> (with a bit of fuzz at the start/end of the workload when spawning the
> processes). All tests were done with a duration of 6 hours.
>
> v6.17
> o ~5400 IPIs received, so about ~200 interfering IPI per isolated CPU
> o About one interfering IPI just shy of every 2 minutes
>
> v6.17 + patches
> o Zilch!
Nice. :)
About performance, can we assume housekeeping CPUs are not affected by
the change (they don't seem to use the trick anyway) or do we want/need
to collect some numbers on them as well just in case (maybe more
throughput oriented)?
Thanks,
Juri
More information about the linux-riscv
mailing list