From: Ben Horgan <ben.horgan@arm.com>
To: Koba Ko <kobak@nvidia.com>
Cc: amitsinght@marvell.com, baisheng.gao@unisoc.com,
baolin.wang@linux.alibaba.com, carl@os.amperecomputing.com,
dave.martin@arm.com, david@kernel.org, dfustini@baylibre.com,
fenghuay@nvidia.com, gshan@redhat.com, james.morse@arm.com,
jic23@kernel.org, lcherian@marvell.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, peternewman@google.com,
punit.agrawal@oss.qualcomm.com, quic_jiles@quicinc.com,
reinette.chatre@intel.com, rohit.mathew@arm.com,
scott@os.amperecomputing.com, sdonthineni@nvidia.com,
tan.shaopeng@fujitsu.com, xhao@linux.alibaba.com,
zengheng4@huawei.com, x86@kernel.org
Subject: Re: [PATCH v4 2/5] arm_mpam: resctrl: Pre-allocate assignable monitors
Date: Tue, 26 May 2026 09:47:06 +0100 [thread overview]
Message-ID: <4103d7b6-7f69-4e9a-b31c-488f54d36e66@arm.com> (raw)
In-Reply-To: <1aea92be-0e7c-459c-a96c-5a54cea073ff@nvidia.com>
Hi Koba,
On 5/26/26 03:50, Koba Ko wrote:
>
>>
>> +/*
>> + * This must run after all event counters have been picked so that any free
>> + * running counters have already been allocated.
>> + */
>> +static int mpam_resctrl_monitor_init_abmc(struct mpam_resctrl_mon *mon)
>> +{
>> + struct mpam_resctrl_res *res = &mpam_resctrl_controls[RDT_RESOURCE_L3];
>> + size_t num_rmid = resctrl_arch_system_num_rmid_idx();
>> + struct rdt_resource *l3 = &res->resctrl_res;
>> + struct mpam_class *class = mon->class;
>> + u16 num_mbwu_mon;
>> + int *cntrs;
>> +
>> + int *rmid_array __free(kvfree) = kvmalloc_objs(*rmid_array, num_rmid);
>> + if (!rmid_array) {
>> + pr_debug("Failed to allocate RMID array\n");
>> + return -ENOMEM;
>> + }
>> + memset(rmid_array, -1, num_rmid * sizeof(*rmid_array));
>> +
>> + num_mbwu_mon = class->props.num_mbwu_mon;
>> + cntrs = __alloc_mbwu_array(mon->class, num_mbwu_mon);
>
> hi Ben,
> One thing double-checking here.
> The allocation path uses class->props.num_mbwu_mon,
> but teardown frees using l3_num_allocated_mbwu,
> which is the global minimum exposed counter counter.
> If classes can have different num_mbwu_mon values, a class with more
> monitors than the global minimum may leak the tail of assigned_counters during
> teardown.
>
> koba
Thanks for bringing this up. The l3_num_allocated_mbwu is a hangover from when
this code supported both mbm_total_bytes and mbm_local_bytes with a separate
class for each. As we've now decided that mbm_total_bytes is the only bandwidth
counter it makes sense to support we will always have at most single class with
allocated bandwidth counters. Hence, I don't think there is a leak but
l3_num_allocated_mbwu adds unneeeded complication so I'll have a go at removing it.
Thanks,
Ben
>
>> + if (IS_ERR(cntrs))
>> + return PTR_ERR(cntrs);
>> + mon->assigned_counters = cntrs;
>> + mon->mbwu_idx_to_mon = no_free_ptr(rmid_array);
>> +
>> + l3->mon.mbm_cntr_assignable = true;
>> + l3->mon.mbm_assign_on_mkdir = true;
>> + l3->mon.mbm_cntr_configurable = false;
>> + l3->mon.mbm_cntr_assign_fixed = true;
>> +
>> + mpam_resctrl_monitor_sync_abmc_vals(l3);
>> +
>> + return 0;
>> +}
>> +
>> static int mpam_resctrl_monitor_init(struct mpam_resctrl_mon *mon,
>> enum resctrl_event_id type)
>> {
>> @@ -1133,8 +1234,21 @@ static int mpam_resctrl_monitor_init(struct
>> mpam_resctrl_mon *mon,
>> */
>> l3->mon.num_rmid = resctrl_arch_system_num_rmid_idx();
>>
>> - if (resctrl_enable_mon_event(type, false, 0, NULL))
>> - l3->mon_capable = true;
>> + if (type == QOS_L3_MBM_TOTAL_EVENT_ID) {
>> + int err;
>> +
>> + err = mpam_resctrl_monitor_init_abmc(mon);
>> + if (err)
>> + return err;
>> +
>> + static_assert(MAX_EVT_CONFIG_BITS == 0x7f);
>> + l3->mon.mbm_cfg_mask = MAX_EVT_CONFIG_BITS;
>> + }
>> +
>> + if (!resctrl_enable_mon_event(type, false, 0, NULL))
>> + return -EINVAL;
>> +
>> + l3->mon_capable = true;
>>
>> return 0;
>> }
>> @@ -1697,6 +1811,23 @@ void mpam_resctrl_exit(void)
>> resctrl_exit();
>> }
>>
>> +static void mpam_resctrl_teardown_mon(struct mpam_resctrl_mon *mon, struct
>> mpam_class *class)
>> +{
>> + u32 num_mbwu_mon = l3_num_allocated_mbwu;
>> +
>> + if (!mon->mbwu_idx_to_mon)
>> + return;
>> +
>> + if (mon->assigned_counters) {
>> + __free_mbwu_mon(class, mon->assigned_counters, num_mbwu_mon);
>> + kvfree(mon->assigned_counters);
>> + mon->assigned_counters = NULL;
>> + }
>> +
>> + kvfree(mon->mbwu_idx_to_mon);
>> + mon->mbwu_idx_to_mon = NULL;
>> +}
>> +
>> /*
>> * The driver is detaching an MSC from this class, if resctrl was using it,
>> * pull on resctrl_exit().
>> @@ -1719,6 +1850,8 @@ void mpam_resctrl_teardown_class(struct mpam_class *class)
>> for_each_mpam_resctrl_mon(mon, eventid) {
>> if (mon->class == class) {
>> mon->class = NULL;
>> +
>> + mpam_resctrl_teardown_mon(mon, class);
>> break;
>> }
>> }
>> --
>> 2.43.0
>>
next prev parent reply other threads:[~2026-05-26 8:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 21:24 [PATCH v4 0/5] arm_mpam: resctrl: Counter Assignment (ABMC) Ben Horgan
2026-05-20 21:24 ` [PATCH v4 1/5] arm_mpam: resctrl: Pick classes for use as MBM counters Ben Horgan
2026-05-20 21:24 ` [PATCH v4 2/5] arm_mpam: resctrl: Pre-allocate assignable monitors Ben Horgan
2026-05-26 2:50 ` Koba Ko
2026-05-26 8:47 ` Ben Horgan [this message]
2026-05-20 21:24 ` [PATCH v4 3/5] arm_mpam: resctrl: Add resctrl_arch_config_cntr() for ABMC use Ben Horgan
2026-05-20 21:24 ` [PATCH v4 4/5] arm_mpam: resctrl: Add resctrl_arch_cntr_read() & resctrl_arch_reset_cntr() Ben Horgan
2026-05-20 21:24 ` [PATCH v4 5/5] arm64: mpam: Add memory bandwidth usage (MBWU) documentation Ben Horgan
2026-05-27 0:42 ` [PATCH v4 0/5] arm_mpam: resctrl: Counter Assignment (ABMC) Shaopeng Tan (Fujitsu)
2026-05-27 14:36 ` Ben Horgan
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=4103d7b6-7f69-4e9a-b31c-488f54d36e66@arm.com \
--to=ben.horgan@arm.com \
--cc=amitsinght@marvell.com \
--cc=baisheng.gao@unisoc.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=carl@os.amperecomputing.com \
--cc=dave.martin@arm.com \
--cc=david@kernel.org \
--cc=dfustini@baylibre.com \
--cc=fenghuay@nvidia.com \
--cc=gshan@redhat.com \
--cc=james.morse@arm.com \
--cc=jic23@kernel.org \
--cc=kobak@nvidia.com \
--cc=lcherian@marvell.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peternewman@google.com \
--cc=punit.agrawal@oss.qualcomm.com \
--cc=quic_jiles@quicinc.com \
--cc=reinette.chatre@intel.com \
--cc=rohit.mathew@arm.com \
--cc=scott@os.amperecomputing.com \
--cc=sdonthineni@nvidia.com \
--cc=tan.shaopeng@fujitsu.com \
--cc=x86@kernel.org \
--cc=xhao@linux.alibaba.com \
--cc=zengheng4@huawei.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