public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Punit Agrawal <punit.agrawal@oss.qualcomm.com>
To: James Morse <james.morse@arm.com>
Cc: Punit Agrawal <punit.agrawal@oss.qualcomm.com>,
	Ben Horgan <ben.horgan@arm.com>,
	amitsinght@marvell.com, baisheng.gao@unisoc.com,
	baolin.wang@linux.alibaba.com, bobo.shaobowang@huawei.com,
	carl@os.amperecomputing.com, catalin.marinas@arm.com,
	dakr@kernel.org, dave.martin@arm.com, david@redhat.com,
	dfustini@baylibre.com, fenghuay@nvidia.com,
	gregkh@linuxfoundation.org, gshan@redhat.com,
	guohanjun@huawei.com, jeremy.linton@arm.com,
	jonathan.cameron@huawei.com, kobak@nvidia.com,
	lcherian@marvell.com, lenb@kernel.org,
	linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, lpieralisi@kernel.org,
	peternewman@google.com, quic_jiles@quicinc.com,
	rafael@kernel.org, robh@kernel.org, rohit.mathew@arm.com,
	scott@os.amperecomputing.com, sdonthineni@nvidia.com,
	sudeep.holla@arm.com, tan.shaopeng@fujitsu.com, will@kernel.org,
	xhao@linux.alibaba.com, reinette.chatre@intel.com
Subject: Re: [PATCH v6 00/34] arm_mpam: Add basic mpam driver
Date: Fri, 05 Dec 2025 13:08:40 +0000	[thread overview]
Message-ID: <871pl9krdz.fsf@stealth> (raw)
In-Reply-To: <642767c9-f926-490a-83a1-160978c37553@arm.com> (James Morse's message of "Wed, 3 Dec 2025 17:34:37 +0000")

James Morse <james.morse@arm.com> writes:

> Hi Punit,
>
> On 03/12/2025 11:21, Punit Agrawal wrote:
>> Ben Horgan <ben.horgan@arm.com> writes:
>>> On 11/24/25 15:21, Punit Agrawal wrote:
>>>> Although a little late to the party,
>
> There was a party?!
>
>
>>>> I've managed to throw together
>>>> enough firmware to describe the MPAM hardware and take this set (more
>>>> specifically mpam/snapshot/v6.18-rc4-v5 branch from James' repository)
>>>> for a spin. Using the branch, the kernel is able to probe the hardware
>>>> and discover the advertised features. Yay! We are in business.
>>>
>>> Thanks for giving it a go. :)
>>>
>>>>
>>>> Having said that, there are a few quirks of the platform that run into
>>>> issues with later patches in the branch.
>
> So something in the resctrl support code is causing this.
> Any idea which patch causes this to happen?
>
> There are a load of pr_debug() in the picking logic, if you enable DYNDEBUG and add:
> | dyndbg="file mpam_resctrl.c +pl"
>
> to the commandline, you should get some snotty messages about what non-Xeon-like property
> your platform has.

Thanks - I've got this enabled.

The platform looks very different to a Xeon. One notable difference
being a shared L2. Hence all the MSCs attached there.

>>>> The platform has MSCs attached
>>>> to shared L2 caches which are being skipped during later stages of
>>>> initialisation. IIUC, the L2 MSCs' limitations stems from the
>>>> assumptions in the resctrl interface.
>>>
>>> What in particualar is being skipped?
>
>> The registration of the discovered MSCs with resctrl and subsequent
>> exposing it to the user.
>
> resctrl's 'L2' support is limited to the CPOR bitmap.
> If you have controls, there is no resctrl 'event' that can exposed them.
> (the problem being they all have 'L3' in the name!)

>>>> I was wondering if there are any patches available to relax these
>>>> limitations?

> Knowing which property it is will help - but some of these things are checked
> to match resctrl's ABI. They can't necessarily be relaxed without breaking
> user-space.

This platform has portion, capacity and priority partitioning, as well
as memory bandwidth and cache storage monitoring. The MPAM code seems to
correctly parse the properties.

But as you point out, the resctrl 'L2' support doesn't have anything
other than CPOR bitmap yet. Have you looked at what's needed to extend
resctrl to support some of the others?

> Others are sanity checks, e.g. all CPUs are represented. This is to avoid tasks
> that run on cpu-9 escaping the resctrl controls. Platforms that did this may as
> well not bother with resctrl at all.
>
>
>>>> I can give them a try. Or do these need to be put together
>>>> from the ground up? Any pointers greatly appreciated.
>>>
>>> There are some extra things added in the extras branch [1] e.g. cache
>>> maximum usage controls (cmax). However, lots of possible things are
>>> still missing e.g. any monitors on L2. If it doesn't fit with the
>>> topology expected by resctrl then it is unlikely to have been considered
>>> yet.
>> 
>> Thanks for the pointer. I'll give the snapshot+extras branch[1] a try.
>> 
>> The platform does have both controls and monitors attached to L2. If
>> this isn't being looked at, I can try and put something together. Thanks
>> for confirming that the limitation is likely due to resctrl.
>
> My view on 'extra' counters is to try and expose them via perf, as this would also
> allow platform specific counters. I worry that if we start adding 'easy' ones like
> l2_mbm_total to resctrl, someone will want
> left_hand_side_of_soc_mbm_total.

I wouldn't club L2 in the same category as 'left_hand_side_of_soc'. You
call it 'easy' for a reason. L2 is pretty well understood and resctrl
already exposes an interface for it. I would avoid creating a new
interface for users.

For some of the other boundaries, things like 'left_hand_side_of_soc' I
wonder if firmware provided topology (e.g., PPTT, SRAT, etc) could be
used to make even this work.


  reply	other threads:[~2025-12-05 13:08 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-19 12:22 [PATCH v6 00/34] arm_mpam: Add basic mpam driver Ben Horgan
2025-11-19 12:22 ` [PATCH v6 01/34] ACPI / PPTT: Add a helper to fill a cpumask from a processor container Ben Horgan
2025-11-19 17:08   ` Jeremy Linton
2025-11-19 12:22 ` [PATCH v6 02/34] ACPI / PPTT: Stop acpi_count_levels() expecting callers to clear levels Ben Horgan
2025-11-19 17:08   ` Jeremy Linton
2025-11-19 12:22 ` [PATCH v6 03/34] ACPI / PPTT: Add acpi_pptt_cache_v1_full to use pptt cache as one structure Ben Horgan
2025-11-19 17:08   ` Jeremy Linton
2025-11-19 12:22 ` [PATCH v6 04/34] ACPI / PPTT: Find cache level by cache-id Ben Horgan
2025-11-19 17:09   ` Jeremy Linton
2025-11-19 12:22 ` [PATCH v6 05/34] ACPI / PPTT: Add a helper to fill a cpumask from a cache_id Ben Horgan
2025-11-19 17:09   ` Jeremy Linton
2025-11-19 12:22 ` [PATCH v6 06/34] arm64: kconfig: Add Kconfig entry for MPAM Ben Horgan
2025-11-19 12:22 ` [PATCH v6 07/34] platform: Define platform_device_put cleanup handler Ben Horgan
2025-11-19 12:22 ` [PATCH v6 08/34] ACPI: Define acpi_put_table cleanup handler and acpi_get_table_pointer() helper Ben Horgan
2025-11-19 12:22 ` [PATCH v6 09/34] ACPI / MPAM: Parse the MPAM table Ben Horgan
2025-11-19 12:22 ` [PATCH v6 10/34] arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate Ben Horgan
2025-11-19 12:22 ` [PATCH v6 11/34] arm_mpam: Add the class and component structures for firmware described ris Ben Horgan
2025-11-19 12:22 ` [PATCH v6 12/34] arm_mpam: Add MPAM MSC register layout definitions Ben Horgan
2025-11-19 12:22 ` [PATCH v6 13/34] arm_mpam: Add cpuhp callbacks to probe MSC hardware Ben Horgan
2025-11-19 12:22 ` [PATCH v6 14/34] arm_mpam: Probe hardware to find the supported partid/pmg values Ben Horgan
2025-11-19 12:22 ` [PATCH v6 15/34] arm_mpam: Add helpers for managing the locking around the mon_sel registers Ben Horgan
2025-11-19 12:22 ` [PATCH v6 16/34] arm_mpam: Probe the hardware features resctrl supports Ben Horgan
2025-11-19 12:22 ` [PATCH v6 17/34] arm_mpam: Merge supported features during mpam_enable() into mpam_class Ben Horgan
2025-11-19 12:22 ` [PATCH v6 18/34] arm_mpam: Reset MSC controls from cpuhp callbacks Ben Horgan
2025-11-19 12:22 ` [PATCH v6 19/34] arm_mpam: Add a helper to touch an MSC from any CPU Ben Horgan
2025-11-19 12:22 ` [PATCH v6 20/34] arm_mpam: Extend reset logic to allow devices to be reset any time Ben Horgan
2025-11-19 12:22 ` [PATCH v6 21/34] arm_mpam: Register and enable IRQs Ben Horgan
2025-11-19 12:22 ` [PATCH v6 22/34] arm_mpam: Use a static key to indicate when mpam is enabled Ben Horgan
2025-11-19 12:22 ` [PATCH v6 23/34] arm_mpam: Allow configuration to be applied and restored during cpu online Ben Horgan
2025-11-19 12:22 ` [PATCH v6 24/34] arm_mpam: Probe and reset the rest of the features Ben Horgan
2025-11-19 12:22 ` [PATCH v6 25/34] arm_mpam: Add helpers to allocate monitors Ben Horgan
2025-11-19 12:22 ` [PATCH v6 26/34] arm_mpam: Add mpam_msmon_read() to read monitor value Ben Horgan
2025-11-19 12:22 ` [PATCH v6 27/34] arm_mpam: Track bandwidth counter state for power management Ben Horgan
2025-11-19 12:22 ` [PATCH v6 28/34] arm_mpam: Consider overflow in bandwidth counter state Ben Horgan
2025-11-19 12:22 ` [PATCH v6 29/34] arm_mpam: Probe for long/lwd mbwu counters Ben Horgan
2025-11-19 12:23 ` [PATCH v6 30/34] arm_mpam: Use long MBWU counters if supported Ben Horgan
2025-11-19 12:23 ` [PATCH v6 31/34] arm_mpam: Add helper to reset saved mbwu state Ben Horgan
2025-11-19 12:23 ` [PATCH v6 32/34] arm_mpam: Add kunit test for bitmap reset Ben Horgan
2025-11-19 12:23 ` [PATCH v6 33/34] arm_mpam: Add kunit tests for props_mismatch() Ben Horgan
2025-11-19 12:23 ` [PATCH v6 34/34] MAINTAINERS: new entry for MPAM Driver Ben Horgan
2025-11-19 19:14 ` [PATCH v6 00/34] arm_mpam: Add basic mpam driver Catalin Marinas
2025-11-24 15:21 ` Punit Agrawal
2025-11-27 14:25   ` Ben Horgan
2025-12-03 11:21     ` Punit Agrawal
2025-12-03 17:34       ` James Morse
2025-12-05 13:08         ` Punit Agrawal [this message]
2025-12-05 19:11           ` Reinette Chatre
2025-12-08 17:43             ` Punit Agrawal
2025-12-08 18:21               ` Reinette Chatre

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=871pl9krdz.fsf@stealth \
    --to=punit.agrawal@oss.qualcomm.com \
    --cc=amitsinght@marvell.com \
    --cc=baisheng.gao@unisoc.com \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=ben.horgan@arm.com \
    --cc=bobo.shaobowang@huawei.com \
    --cc=carl@os.amperecomputing.com \
    --cc=catalin.marinas@arm.com \
    --cc=dakr@kernel.org \
    --cc=dave.martin@arm.com \
    --cc=david@redhat.com \
    --cc=dfustini@baylibre.com \
    --cc=fenghuay@nvidia.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gshan@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=james.morse@arm.com \
    --cc=jeremy.linton@arm.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=kobak@nvidia.com \
    --cc=lcherian@marvell.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=peternewman@google.com \
    --cc=quic_jiles@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=reinette.chatre@intel.com \
    --cc=robh@kernel.org \
    --cc=rohit.mathew@arm.com \
    --cc=scott@os.amperecomputing.com \
    --cc=sdonthineni@nvidia.com \
    --cc=sudeep.holla@arm.com \
    --cc=tan.shaopeng@fujitsu.com \
    --cc=will@kernel.org \
    --cc=xhao@linux.alibaba.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