Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Rong Xu <xur@google.com>
Cc: Yabin Cui <yabinc@google.com>, Will Deacon <will@kernel.org>,
	Han Shen <shenhan@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Kees Cook <kees@kernel.org>,
	Nicolas Schier <nicolas.schier@linux.dev>,
	Linus Walleij <linusw@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Jinjie Ruan <ruanjinjie@huawei.com>,
	Lukas Bulwahn <lukas.bulwahn@redhat.com>,
	linux-kernel@vger.kernel.org, Juergen Gross <jgross@suse.com>,
	Helge Deller <deller@gmx.de>, Ryan Roberts <ryan.roberts@arm.com>,
	Marc Zyngier <maz@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	Vincent Donnefort <vdonnefort@google.com>,
	Alice Ryhl <aliceryhl@google.com>,
	x86@kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/2] kconfig: Remove the architecture specific config for AutoFDO
Date: Mon, 1 Jun 2026 12:24:58 -0700	[thread overview]
Message-ID: <20260601192458.GB965997@ax162> (raw)
In-Reply-To: <CAF1bQ=S4EaOQz6QLAUzXhiMqucTxPHvXiAQ6Rvfct18uXgPzYw@mail.gmail.com>

On Mon, Jun 01, 2026 at 09:52:56AM -0700, Rong Xu wrote:
> On Fri, May 29, 2026 at 5:47 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > On Wed, 27 May 2026 14:45:07 -0700, xur@google.com <xur@google.com> wrote:
> > > The CONFIG_AUTOFDO_CLANG option currently depends on
> > > ARCH_SUPPORTS_AUTOFDO_CLANG, but this dependency seems unnecessary.
> > >
> > > Remove ARCH_SUPPORTS_AUTOFDO_CLANG and allow users to control AutoFDO
> > > builds solely through CONFIG_AUTOFDO_CLANG. This simplifies the kconfig
> > > and avoids potential confusion.
> >
> > It is worth noting that not all architectures support
> > '-fsplit-machine-functions' but I guess that does not matter too much
> > because it will only be used if a profile is provided, which would
> > require an architecture that is supported by the AutoFDO tooling? The
> > documentation is x86_64 focused but aarch64 works as well, any others
> > that the kernel supports?
> 
> Current support extends to x86_64 and arm64 architectures only.
> 
> We initially considered making arm64 to opt-in, Will suggests that users should
> be expected to verify AutoFDO/Propeller compatibility independently
> before using it.
> This approach allows for the removal of ARCH_SUPPORTS_..., which prevents
> potential confusion.

Right, in cases where the build does not break (i.e., this case), I
think it is fine to leave things open to selection and restrict them
when they become confusing or problematic for users based on real
feedback.

-- 
Cheers,
Nathan


  reply	other threads:[~2026-06-01 19:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-27 21:45 [PATCH v3 0/2] kconfig: Remove the architecture specific config for AutoFDO and Propeller xur
2026-05-27 21:45 ` [PATCH v3 1/2] kconfig: Remove the architecture specific config for AutoFDO xur
2026-05-30  0:47   ` Nathan Chancellor
2026-06-01 16:52     ` Rong Xu
2026-06-01 19:24       ` Nathan Chancellor [this message]
2026-05-27 21:45 ` [PATCH v3 2/2] kconfig: Remove the architecture specific config for Propeller xur
2026-05-30  0:47   ` Nathan Chancellor
2026-06-01 18:18     ` Rong Xu
2026-06-02  9:43       ` Will Deacon
2026-06-02 17:52         ` Rong Xu
2026-06-03  1:53           ` Nathan Chancellor
2026-06-03 22:15             ` Rong Xu
2026-05-29 16:32 ` [PATCH v3 0/2] kconfig: Remove the architecture specific config for AutoFDO and Propeller Will Deacon

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=20260601192458.GB965997@ax162 \
    --to=nathan@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=deller@gmx.de \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=kees@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@redhat.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=maz@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nicolas.schier@linux.dev \
    --cc=ojeda@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ruanjinjie@huawei.com \
    --cc=ryan.roberts@arm.com \
    --cc=shenhan@google.com \
    --cc=tglx@linutronix.de \
    --cc=vdonnefort@google.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=xur@google.com \
    --cc=yabinc@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