Re: [PATCH -tip] x86/locking/atomic: Use asm_inline for atomic locking insns

[Uros Bizjak <ubizjak@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

On Fri, Feb 28, 2025 at 5:48 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 2/28/25 04:35, Uros Bizjak wrote:
> > The code size of the resulting x86_64 defconfig object file increases
> > for 33.264 kbytes, representing 1.2% code size increase:
> >
> >    text    data     bss     dec     hex filename
> > 27450107        4633332  814148 32897587        1f5fa33 vmlinux-old.o
> > 27483371        4633784  814148 32931303        1f67de7 vmlinux-new.o
>
> So, first of all, thank you for including some objective measurement of
> the impact if your patches. It's much appreciated.
>
> But I think the patches need to come with a solid theory of why they're
> good. The minimum bar for that, I think, is *some* kind of actual
> real-world performance test. I'm not picky. Just *something* that spends
> a lot of time in the kernel and ideally where a profile points at some
> of the code you're poking here.
>
> I'm seriously not picky: will-it-scale, lmbench, dbench, kernel
> compiles. *ANYTHING*. *ANY* hardware. Run it on your laptop.
>
> But performance patches need to come with performance *numbers*.

Please find lmbench results from unpatched (fedora.0) and patched
(fedora.1) fedora-41 6.13.5 kernels.

lmbench is from [1]

[1] https://fedora.pkgs.org/41/rpm-sphere-x86_64/lmbench-3.0-0.a9.3.x86_64.rpm.html

Some tests show quite different results, but I'd appreciate some help
in interpreting the results. Maybe they show that the price of 33
kbytes is worth the improvement, or they will motivate someone
experienced in kernel benchmarks to benchmark the patch in a more
scientific way.

Thanks,
Uros.

[-- Attachment #2: results.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 7736 bytes --]