From: Nathan Chancellor <nathan@kernel.org>
To: Douglas Anderson <dianders@chromium.org>
Cc: llvm@lists.linux.dev, linux-kbuild@vger.kernel.org,
"Rong Xu" <xur@google.com>, "Han Shen" <shenhan@google.com>,
"Nicolas Schier" <nsc@kernel.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Han Wang" <nesthanwang@google.com>,
"Alexandre Courbot" <acourbot@nvidia.com>,
"Alice Ryhl" <aliceryhl@google.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Benno Lossin" <lossin@kernel.org>,
"Bill Wendling" <morbo@google.com>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Boqun Feng" <boqun@kernel.org>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Gary Guo" <gary@garyguo.net>,
"Justin Stitt" <justinstitt@google.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Onur Özkan" <work@onurozkan.dev>,
"Tamir Duberstein" <tamird@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH] kbuild: AutoFDO: Enable -salvage-stale-profile
Date: Wed, 4 Nov 2026 22:24:01 -0700 [thread overview]
Message-ID: <20261105052401.GA862715@ax162> (raw)
In-Reply-To: <20261104174554.1.I8556199ea4f1335169ce16e97309aa63ae2e2310@changeid>
On Wed, Nov 04, 2026 at 05:45:55PM -0800, Douglas Anderson wrote:
> From: Han Wang <nesthanwang@google.com>
>
> AutoFDO profiles are commonly collected on one kernel revision and
> reused across subsequent commits or stable merges before a fresh
> profile is generated. While AutoFDO uses function-relative line
> numbers to tolerate edits above a function, adding or removing lines
> inside a function (or an inlined helper) shifts all subsequent
> relative line offsets within that function. Without stale profile
> salvaging, shifted callsites fail to match their nested inlinee
> profiles in SampleProfileLoader (dropping profile-guided inlining for
> those callees) and basic block sample counts are misattributed to the
> wrong instructions, degrading branch probability estimation and
> machine function splitting.
>
> Enable LLVM stale profile salvaging (-salvage-stale-profile, supported
> since LLVM 17) for C, Rust, and ThinLTO builds when
> CLANG_AUTOFDO_PROFILE is specified. This instructs SampleProfileMatcher
> to use lexical callsite anchors within functions to fuzzy-match and
> remap shifted line offsets when querying the profile.
>
> While -salvage-stale-profile is not enabled by default in LLVM due to
> the minor compile-time/memory cost of sequence-matching callsite
> anchors (which is unnecessary when profiles are freshly generated on
> the exact commit being built) and the heuristic nature of fuzzy
> matching on heavily rewritten functions, enabling it makes sense for
> the kernel: hardware PMU profiles are rarely regenerated on every
> commit, and anchoring on callsite names is strictly more resilient
> than blind line-offset lookup when functions are edited.
>
> As a side benefit, remapping shifted line offsets also avoids feeding
> mismatched weights from stale profiles into MIRProfileLoader's flow
> inference solver (applyFlowInference), working around a compiler bug
> [1] where a small intra-function line shift (such as in
> __vm_normal_page() in mm/memory.c) can cause applyFlowInference to
> spend 30+ minutes compiling unmap_page_range().
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/2188 [1]
> Signed-off-by: Han Wang <nesthanwang@google.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> Much of the commit-message justification here is AI-generated. Sorry!
> :( Folks who know better, feel free to call bullshit.
The justification does not seem wrong to me on initial read but it
definitely feels like the first and third paragraphs could be reduced in
verbosity since this can basically be summarized by "AutoFDO profiles
are often reused, which can be problematic without profile salvaging
enabled, which is designed for this exact situation".
> Honestly, this patch came about because of AI analysis compiles taking
> 30 minutes to run (see the clang bug [1]). It seems to work around the
> problem. Obviously, we should fix the compiler. That being said, upon
> further analysis it seemed like adding this flag was beneficial
> anyway, so I'm posting it upstream. If folks disagree, we can simply
> drop this patch.
I would definitely like to see that issue triaged but like you say, it
probably does not need to done before this is merged since it has
reasonable justification on its own. I would love to get thoughts from
other folks though.
> scripts/Makefile.autofdo | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/scripts/Makefile.autofdo b/scripts/Makefile.autofdo
> index 57a3aba6ffc2..3b1e65a13ffa 100644
> --- a/scripts/Makefile.autofdo
> +++ b/scripts/Makefile.autofdo
> @@ -13,13 +13,16 @@ endif
> ifdef CLANG_AUTOFDO_PROFILE
> CFLAGS_AUTOFDO_CLANG += -fprofile-sample-use=$(CLANG_AUTOFDO_PROFILE) -ffunction-sections
> CFLAGS_AUTOFDO_CLANG += -fsplit-machine-functions
> + CFLAGS_AUTOFDO_CLANG += -mllvm -salvage-stale-profile
> RUSTFLAGS_AUTOFDO_CLANG += -Zprofile-sample-use=$(CLANG_AUTOFDO_PROFILE) -Zfunction-sections=y
> RUSTFLAGS_AUTOFDO_CLANG += -Cllvm-args=-split-machine-functions
> + RUSTFLAGS_AUTOFDO_CLANG += -Cllvm-args=-salvage-stale-profile
> endif
>
> ifdef CONFIG_LTO_CLANG_THIN
> ifdef CLANG_AUTOFDO_PROFILE
> KBUILD_LDFLAGS += --lto-sample-profile=$(CLANG_AUTOFDO_PROFILE)
> + KBUILD_LDFLAGS += --mllvm=-salvage-stale-profile
> endif
> KBUILD_LDFLAGS += --mllvm=-enable-fs-discriminator=true --mllvm=-improved-fs-discriminator=true -plugin-opt=thinlto
> KBUILD_LDFLAGS += $(call ld-option,-plugin-opt=-function-splitting=all,-plugin-opt=-split-machine-functions)
> --
> 2.56.0.455.g6c5a503b38-goog
>
--
Cheers,
Nathan
next prev parent reply other threads:[~2026-11-05 5:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 1:45 [PATCH] kbuild: AutoFDO: Enable -salvage-stale-profile Douglas Anderson
2026-11-05 5:24 ` Nathan Chancellor [this message]
2026-11-05 16:24 ` Doug Anderson
2026-11-05 18:23 ` Rong Xu
2026-11-05 21:30 ` Doug Anderson
2026-11-05 22:37 ` Nick Desaulniers
2026-11-05 22:40 ` Nick Desaulniers
2026-11-05 19:47 ` Miguel Ojeda
2026-11-05 21:36 ` Doug Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261105052401.GA862715@ax162 \
--to=nathan@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dianders@chromium.org \
--cc=gary@garyguo.net \
--cc=justinstitt@google.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=lossin@kernel.org \
--cc=morbo@google.com \
--cc=ndesaulniers@google.com \
--cc=nesthanwang@google.com \
--cc=nsc@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=shenhan@google.com \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=work@onurozkan.dev \
--cc=xur@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox