From: Breno Leitao <leitao@debian.org>
To: Koba Ko <kobak@nvidia.com>
Cc: Will Deacon <will@kernel.org>,
catalin.marinas@arm.com, robh@kernel.org, corbet@lwn.net,
skhan@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, fenghuay@nvidia.com,
tdave@nvidia.com, kaihengf@nvidia.com, rupakr@nvidia.com,
mohammedk@nvidia.com
Subject: Re: [RFC PATCH v2 1/3] arm64: add CPU prefetch and cache modulation sysfs interface
Date: Wed, 14 Oct 2026 02:17:33 -0700 [thread overview]
Message-ID: <as9HWuAhOGMfH1Ty@gmail.com> (raw)
In-Reply-To: <20261014061745.40032-1-kobak@nvidia.com>
On Wed, Oct 14, 2026 at 02:17:45PM +0800, Koba Ko wrote:
> For controlled performance characterization, is there an existing kernel
> mechanism or a different design you would recommend? Or do you think these
> experimental controls are better kept out of tree?
As a user of this patchset, I am trying hard to avoid carrying it out
of tree, either as patches or as a driver. Out-of-tree code makes
kernel rebases and rollouts slower, and debugging more complex.
Is there a way to keep a generic interface available under
CONFIG_EXPERT, or something similar, so that users who want to
experiment can use it?
We could even taint the kernel when the interface is used, to make it
clear that the user is messing with things they should not (!?).
Thanks,
--breno
next prev parent reply other threads:[~2026-10-14 9:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 18:16 [RFC PATCH v2 0/3] arm64: expose CPU prefetch and cache modulation controls Koba Ko
2026-08-25 18:16 ` [RFC PATCH v2 1/3] arm64: add CPU prefetch and cache modulation sysfs interface Koba Ko
2026-09-29 13:29 ` Will Deacon
2026-10-14 6:17 ` Koba Ko
2026-10-14 9:17 ` Breno Leitao [this message]
2026-08-25 18:17 ` [RFC PATCH v2 2/3] Documentation/arch/arm64: document arm_cpumod Koba Ko
2026-08-25 18:17 ` [RFC PATCH v2 3/3] selftests: arm64: add arm_cpumod kselftest Koba Ko
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=as9HWuAhOGMfH1Ty@gmail.com \
--to=leitao@debian.org \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=fenghuay@nvidia.com \
--cc=kaihengf@nvidia.com \
--cc=kobak@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mohammedk@nvidia.com \
--cc=robh@kernel.org \
--cc=rupakr@nvidia.com \
--cc=skhan@linuxfoundation.org \
--cc=tdave@nvidia.com \
--cc=will@kernel.org \
/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