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

Ingo Molnar
2025-03-06T10:38:38Z

* Uros Bizjak <ubizjak@gmail.com> wrote:

> > So these are roughly the high level requirements around such patches.
> > Does this make sense?
>
> In my opinion, the writing above makes perfect sense. As far as I'm
> concerned, I'm able and can do the above code analysis, the
> problematic part would be precise performance measurements. Although
> with your instructions, I can also try that.

Yeah, so *personally* I find the kind of code generation analysis you
routinely perform for your micro-optimization patches far more useful
and persuasive, because it's basically a first principles argument:
instructions removed are an inarguable positive in the overwhelming
majority cases all other things equal (as long as it doesn't come at
the expense of more function calls or worse instructions, etc.).

For inlining decisions code generation analysis is arguably more
complicated - but that's the nature of inlining related patches.

Performance measurements can back up such arguments, and being more
proficient in perf tooling is a useful toolbox to have anyway, but it's
fundamentally a stohastic argument for something as comparatively small
as a +0.12% code size increase.

But if code generation analysis is inconclusive or even negative, then
performance measurements can trump all of that, but it's a substantial
barrier of entry as you noted - and I'm somewhat sceptical whether a
0.12% code generation effect *can* even be measured reliably even with
the best of expertise and infrastructure...

Also, to shorten build & test times you can use the x86-64 defconfig.
It's a config more or less representative of what major distros enable,
and it's even bootable on some systems and in VMs, but it builds in far
less time.

Thanks,

Ingo