[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z9YdQ9fe4NJ1ciyi@gmail.com>
Date: Sun, 16 Mar 2025 01:37:23 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Uros Bizjak <ubizjak@...il.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH] x86/asm: Use asm_inline() instead of asm() in
amd_clear_divider()
* Borislav Petkov <bp@...en8.de> wrote:
> On Fri, Mar 14, 2025 at 11:17:43AM +0100, Ingo Molnar wrote:
> > Here's a link for those who'd like to view this via the web:
> >
> > https://lore.kernel.org/all/174188884263.14745.1542926632284353047.tip-bot2@tip-bot2/
>
> This is a perf measuring method I got from you, actually, from a long time
> ago:
>
> :-)
>
> ./tools/perf/perf stat -a --repeat 5 --sync --pre ~/bin/pre-build-kernel.sh -- make -s -j33 bzImage
Yeah, so that's a suboptimal test for these particular changes really:
why would a simple CPU-saturated kernel build with low levels of kernel
use of the affected areas show measurable changes with this commit?
> This is all within the noise.
Should we expect anything else from this test?
Also, see the other figures & analysis within the commit, in particular
the reduction in the number of function calls, when we have high
per-function mitigation overhead that is often the top entry in kernel
profiles:
Overhead Shared Object Symbol
4.57% [kernel] [k] retbleed_return_thunk
4.40% [kernel] [k] unmap_page_range
4.31% [kernel] [k] _copy_to_iter
2.46% [kernel] [k] memset_orig
2.31% libc.so.6 [.] __cxa_finalize
Each eliminated function call from when GCC's inliner was formerly
confused by Linux's asm() statements is a win.
I did a test too, with a pipe-scheduling workload of 'perf bench sched
pipe' locked down to a single CPU, with CPU frequencies fixed and
nested perf stat instances:
kepler:~> taskset -c 2 perf stat --null --repeat 5 perf stat --null --repeat 5 perf bench sched pipe
[ -vanilla ] 19.5514 +- 0.0235 seconds time elapsed ( +- 0.12% )
[ +Uros's commit: ] 19.3972 +- 0.0207 seconds time elapsed ( +- 0.11% )
Notes:
- Best of 3 runs
- "+Uros's commit" is the aforementioned one from -tip that you measured too:
9628d19e91f1 ("x86/locking/atomic: Improve performance by using asm_inline() for atomic locking instructions") applied: ]
# https://lore.kernel.org/all/174188884263.14745.1542926632284353047.tip-bot2@tip-bot2/
- The nested perf stat instances allowed further reduction in
measurement stddev, while keeping the internal steps easily
observable, verifiable while the total runtime is still reasonable.
So on my system there appears to be a measurable improvement in
performance on this particular benchmark on the order of magnitude of
around ~0.8%, which is outside the measurement noise of around ~0.2%.
Thanks,
Ingo
Powered by blists - more mailing lists