[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <293395d7-5766-45df-a2e0-1542fecda5a7@arm.com>
Date: Tue, 4 Nov 2025 10:24:50 +0000
From: Ben Horgan <ben.horgan@....com>
To: Zeng Heng <zengheng4@...wei.com>, james.morse@....com
Cc: amitsinght@...vell.com, baisheng.gao@...soc.com,
baolin.wang@...ux.alibaba.com, carl@...amperecomputing.com,
catalin.marinas@....com, dakr@...nel.org, dave.martin@....com,
david@...hat.com, dfustini@...libre.com, fenghuay@...dia.com,
gregkh@...uxfoundation.org, gshan@...hat.com, guohanjun@...wei.com,
jeremy.linton@....com, jonathan.cameron@...wei.com, kobak@...dia.com,
lcherian@...vell.com, lenb@...nel.org, linux-acpi@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
lpieralisi@...nel.org, peternewman@...gle.com, quic_jiles@...cinc.com,
rafael@...nel.org, robh@...nel.org, rohit.mathew@....com,
scott@...amperecomputing.com, sdonthineni@...dia.com, sudeep.holla@....com,
tan.shaopeng@...itsu.com, will@...nel.org, xhao@...ux.alibaba.com,
wangkefeng.wang@...wei.com, sunnanyong@...wei.com
Subject: Re: [PATCH v2] arm64/mpam: Clean MBWU monitor overflow bit
Hi Zeng,
On 11/3/25 03:47, Zeng Heng wrote:
> Hi Ben,
>
> On 2025/10/30 17:52, Ben Horgan wrote:
>> Hi Zeng,
>>
>> On 10/29/25 07:56, Zeng Heng wrote:
>>> The MSMON_MBWU register accumulates counts monotonically forward and
>>> would not automatically cleared to zero on overflow. The overflow
>>> portion
>>> is exactly what mpam_msmon_overflow_val() computes, there is no need to
>>> additionally subtract mbwu_state->prev_val.
>>>
>>> Before invoking write_msmon_ctl_flt_vals(), the overflow bit of the
>>> MSMON_MBWU register must first be read to prevent it from being
>>> inadvertently cleared by the write operation.
>>>
>>> Finally, use the overflow bit instead of relying on counter wrap-around
>>> to determine whether an overflow has occurred, that avoids the case
>>> where
>>> a wrap-around (now > prev_val) is overlooked. So with this, prev_val no
>>> longer has any use and remove it.
>>>
>>> CC: Ben Horgan <ben.horgan@....com>
>>> Signed-off-by: Zeng Heng <zengheng4@...wei.com>
>>> ---
>>> drivers/resctrl/mpam_devices.c | 22 +++++++++++++++++-----
>>> drivers/resctrl/mpam_internal.h | 3 ---
>>> 2 files changed, 17 insertions(+), 8 deletions(-)
>>
>> This all looks fine for overflow, but what we've been forgetting about
>> is the power management. As James mentioned in his commit message, the
>> prev_val is after now check is doing double duty. If an msc is powered
>> down and reset then we lose the count. Hence, to keep an accurate count,
>> we should be considering this case too.
>>
>
>
> Regarding CPU power management and CPU on-/off-line scenarios, this
> should and already has been handled by mpam_save_mbwu_state():
>
> 1. Freezes the current MSMON_MBWU counter into the
> mbwu_state->correction;
> 2. Clears the MSMON_MBWU counter;
>
> After the CPU is powered back on, the total bandwidth traffic is
> MSMON_MBWU(the `now` variable) + correction.
>
> So the above solution also covers CPU power-down scenarios, and no
> additional code is needed to adapt to this case.
>
> If I've missed anything, thanks in advance to point it out.
>
No, I don't think you missed anything. You just didn't mention in your commit message
that this is also fixing the power management case.
I'm going to post the next version of this series for James as he is otherwise engaged.
I've taken your patch and adapted it to fit in with the order of patches.
Does this look ok to you? The support for the long counters will be added later.
+static u64 mpam_msmon_overflow_val(enum mpam_device_features type)
+{
+ /* TODO: scaling, and long counters */
+ return BIT_ULL(hweight_long(MSMON___VALUE));
+}
+
static void __ris_msmon_read(void *arg)
{
u64 now;
bool nrdy = false;
bool config_mismatch;
+ bool overflow;
struct mon_read *m = arg;
struct mon_cfg *ctx = m->ctx;
struct mpam_msc_ris *ris = m->ris;
@@ -1008,6 +1015,8 @@ static void __ris_msmon_read(void *arg)
* This saves waiting for 'nrdy' on subsequent reads.
*/
read_msmon_ctl_flt_vals(m, &cur_ctl, &cur_flt);
+ overflow = cur_ctl & MSMON_CFG_x_CTL_OFLOW_STATUS;
+
clean_msmon_ctl_val(&cur_ctl);
gen_msmon_ctl_flt_vals(m, &ctl_val, &flt_val);
config_mismatch = cur_flt != flt_val ||
@@ -1016,6 +1025,9 @@ static void __ris_msmon_read(void *arg)
if (config_mismatch) {
write_msmon_ctl_flt_vals(m, ctl_val, flt_val);
overflow = false;
+ } else if (overflow) {
+ mpam_write_monsel_reg(msc, CFG_MBWU_CTL,
+ cur_ctl & ~MSMON_CFG_x_CTL_OFLOW_STATUS);
}
switch (m->type) {
@@ -1039,7 +1051,10 @@ static void __ris_msmon_read(void *arg)
if (overflow)
mbwu_state->correction += mpam_msmon_overflow_val(m->type);
- /* Include bandwidth consumed before the last hardware reset */
+ /*
+ * Include bandwidth consumed before the last hardware reset and
+ * a counter size increment for each overflow.
+ */
now += mbwu_state->correction;
break;
default:
diff --git a/drivers/resctrl/mpam_internal.h b/drivers/resctrl/mpam_internal.h
index d10edf4c0f0b..7e9390211df7 100644
--- a/drivers/resctrl/mpam_internal.h
+++ b/drivers/resctrl/mpam_internal.h
@@ -209,7 +209,8 @@ struct msmon_mbwu_state {
struct mon_cfg cfg;
/*
- * The value to add to the new reading to account for power management.
+ * The value to add to the new reading to account for power management,
+ * and overflow.
*/
u64 correction;
Thanks,
Ben
Powered by blists - more mailing lists