lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ