[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251218133611.00000a3c@huawei.com>
Date: Thu, 18 Dec 2025 13:36:11 +0000
From: Jonathan Cameron <jonathan.cameron@...wei.com>
To: James Morse <james.morse@....com>
CC: <linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>, D
Scott Phillips OS <scott@...amperecomputing.com>,
<carl@...amperecomputing.com>, <lcherian@...vell.com>,
<bobo.shaobowang@...wei.com>, <tan.shaopeng@...itsu.com>,
<baolin.wang@...ux.alibaba.com>, Jamie Iles <quic_jiles@...cinc.com>, "Xin
Hao" <xhao@...ux.alibaba.com>, <peternewman@...gle.com>,
<dfustini@...libre.com>, <amitsinght@...vell.com>, David Hildenbrand
<david@...nel.org>, Dave Martin <dave.martin@....com>, Koba Ko
<kobak@...dia.com>, Shanker Donthineni <sdonthineni@...dia.com>,
<fenghuay@...dia.com>, <baisheng.gao@...soc.com>, Gavin Shan
<gshan@...hat.com>, Ben Horgan <ben.horgan@....com>, <rohit.mathew@....com>,
<reinette.chatre@...el.com>, Punit Agrawal <punit.agrawal@....qualcomm.com>
Subject: Re: [RFC PATCH 19/38] arm_mpam: resctrl: pick classes for use as
mbm counters
On Fri, 5 Dec 2025 21:58:42 +0000
James Morse <james.morse@....com> wrote:
> resctrl has two types of counters, NUMA-local and global. MPAM has only
> bandwidth counters, but the position of the MSC may mean it counts
> NUMA-local, or global traffic.
>
> But the topology information is not available.
>
> Apply a heuristic: the L2 or L3 supports bandwidth monitors, these are
> probably NUMA-local. If the memory controller supports bandwidth
> monitors, they are probably global.
>
> This also allows us to assert that we don't have the same class
> backing two different resctrl events.
>
> Because the class or component backing the event may not be 'the L3',
> it is necessary for mpam_resctrl_get_domain_from_cpu() to search
> the monitor domains too. This matters the most for 'monitor only'
> systems, where 'the L3' control domains may be empty, and the
> ctrl_comp pointer NULL.
>
> resctrl expects there to be enough monitors for every possible control
> and monitor group to have one. Such a system gets called 'free running'
> as the monitors can be programmed once and left running.
> Any other platform will need to emulate ABMC.
>
> Signed-off-by: James Morse <james.morse@....com>
> ---
> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
> index fc1f054f187e..9978eb48c1f4 100644
> --- a/drivers/resctrl/mpam_resctrl.c
> +++ b/drivers/resctrl/mpam_resctrl.c
> @@ -586,7 +614,37 @@ static void mpam_resctrl_pick_counters(void)
> return;
> }
> }
> +
> + has_mbwu = class_has_usable_mbwu(class);
> + if (has_mbwu && topology_matches_l3(class)) {
Might get reused in later patches. If not
if (class_has_usable_mbwu(class) && topology_matches_l3(class))
> + pr_debug("class %u has usable MBWU, and matches L3 topology",
> + class->level);
> +
> + /*
> + * MBWU counters may be 'local' or 'total' depending on
> + * where they are in the topology. Counters on caches
> + * are assumed to be local. If it's on the memory
> + * controller, its assumed to be global.
> + */
> + switch (class->type) {
> + case MPAM_CLASS_CACHE:
> + counter_update_class(QOS_L3_MBM_LOCAL_EVENT_ID,
> + class);
> + break;
> + case MPAM_CLASS_MEMORY:
> + counter_update_class(QOS_L3_MBM_TOTAL_EVENT_ID,
> + class);
> + break;
> + default:
> + break;
> + }
> + }
> }
> +
> + /* Allocation of MBWU monitors assumes that the class is unique... */
> + if (mpam_resctrl_counters[QOS_L3_MBM_LOCAL_EVENT_ID].class)
> + WARN_ON_ONCE(mpam_resctrl_counters[QOS_L3_MBM_LOCAL_EVENT_ID].class ==
> + mpam_resctrl_counters[QOS_L3_MBM_TOTAL_EVENT_ID].class);
> }
>
> +/*
> + * We know all the monitors are associated with the L3, even if there are no
> + * controls and therefore no control component. Find the cache-id for the CPU
> + * and use that to search for existing resctrl domains.
> + * This relies on mpam_resctrl_pick_domain_id() using the L3 cache-id
> + * for anything that is not a cache.
> + */
> +static struct mpam_resctrl_dom *mpam_resctrl_get_mon_domain_from_cpu(int cpu)
> +{
> + u32 cache_id;
> + struct rdt_mon_domain *mon_d;
> + struct mpam_resctrl_dom *dom;
> + struct mpam_resctrl_res *l3 = &mpam_resctrl_controls[RDT_RESOURCE_L3];
> +
> + if (!l3->class)
> + return NULL;
> + /* TODO: how does this order with cacheinfo updates under cpuhp? */
> + cache_id = get_cpu_cacheinfo_id(cpu, 3);
> + if (cache_id == ~0)
> + return NULL;
> +
> + list_for_each_entry(mon_d, &l3->resctrl_res.mon_domains, hdr.list) {
> + dom = container_of(mon_d, struct mpam_resctrl_dom, resctrl_mon_dom);
Similar comment to one on earlier patch. Can make the list iterator directly
provide dom as that's what it's actually a list of, not rdt_mon_domain structures.
> +
> + if (mon_d->hdr.id == cache_id)
> + return dom;
> + }
> +
> + return NULL;
> +}
> +
> static struct mpam_resctrl_dom *
> mpam_resctrl_get_domain_from_cpu(int cpu, struct mpam_resctrl_res *res)
> {
> struct mpam_resctrl_dom *dom;
> struct rdt_ctrl_domain *ctrl_d;
> + struct rdt_resource *r = &res->resctrl_res;
Push back to original patch.
>
> lockdep_assert_cpus_held();
>
> - list_for_each_entry_rcu(ctrl_d, &res->resctrl_res.ctrl_domains,
> - hdr.list) {
> + list_for_each_entry_rcu(ctrl_d, &r->ctrl_domains, hdr.list) {
> dom = container_of(ctrl_d, struct mpam_resctrl_dom,
> resctrl_ctrl_dom);
>
Powered by blists - more mailing lists