All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koba Ko <kobak@nvidia.com>
To: Will Deacon <will@kernel.org>
Cc: catalin.marinas@arm.com, robh@kernel.org, leitao@debian.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 14:17:45 +0800	[thread overview]
Message-ID: <20261014061745.40032-1-kobak@nvidia.com> (raw)
In-Reply-To: <aru9Rf7BzW3-vcm0@willie-the-truck>

Hi Will,

Thanks for the feedback. I understand that your concern is about exposing
implementation-defined registers to userspace, not simply choosing sysfs
versus debugfs. I'm not planning to submit v3.

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?

Thanks,
Koba

  reply	other threads:[~2026-10-14  6: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 [this message]
2026-10-14  9:17       ` Breno Leitao
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=20261014061745.40032-1-kobak@nvidia.com \
    --to=kobak@nvidia.com \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=fenghuay@nvidia.com \
    --cc=kaihengf@nvidia.com \
    --cc=leitao@debian.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.