[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8e22c81e-5e78-41e0-a81e-0f9826e5edf0@arm.com>
Date: Wed, 22 Oct 2025 17:17:32 +0100
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, bobo.shaobowang@...wei.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
Subject: Re: [PATCH mpam mpam/snapshot/v6.14-rc1] arm64/mpam: Fix MBWU monitor
overflow handling
Hi Zeng,
On 10/22/25 14:39, Zeng Heng wrote:
> Bandwidth counters need to run continuously to correctly reflect the
> bandwidth. When reading the previously configured MSMON_CFG_MBWU_CTL,
> software must recognize that the MSMON_CFG_x_CTL_OFLOW_STATUS bit may
> have been set by hardware because of the counter overflow.
>
> The existing logic incorrectly treats this bit as an indication that the
> monitor configuration has been changed and consequently zeros the MBWU
> statistics by mistake.
By zero-ing when the overflow bit is set we miss out on the counts after
the overflow and before the zero-ing. Do I understand correctly, that
this what this patch is aiming to fix?
>
> Also fix the handling of overflow amount calculation. There's no need to
> subtract mbwu_state->prev_val when calculating overflow_val.
Why not? Isn't this the pre-overflow part that we are missing from the
running count?
>
> Signed-off-by: Zeng Heng <zengheng4@...wei.com>
> ---
> drivers/resctrl/mpam_devices.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index 0dd048279e02..06f3ec9887d2 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -1101,7 +1101,8 @@ static void __ris_msmon_read(void *arg)
> clean_msmon_ctl_val(&cur_ctl);
> gen_msmon_ctl_flt_vals(m, &ctl_val, &flt_val);
> config_mismatch = cur_flt != flt_val ||
> - cur_ctl != (ctl_val | MSMON_CFG_x_CTL_EN);
> + (cur_ctl & ~MSMON_CFG_x_CTL_OFLOW_STATUS) !=
> + (ctl_val | MSMON_CFG_x_CTL_EN);
This only considers 31 bit counters. I would expect any change here to
consider all lengths of counter. Also, as the overflow bit is no longer
reset due to the config mismatch it needs to be reset somewhere else.
>
> if (config_mismatch || reset_on_next_read)
> write_msmon_ctl_flt_vals(m, ctl_val, flt_val);
> @@ -1138,8 +1139,9 @@ static void __ris_msmon_read(void *arg)
> mbwu_state = &ris->mbwu_state[ctx->mon];
>
> /* Add any pre-overflow value to the mbwu_state->val */
> - if (mbwu_state->prev_val > now)
> - overflow_val = mpam_msmon_overflow_val(m->type) - mbwu_state->prev_val;
> + if (mbwu_state->prev_val > now &&
> + (cur_ctl & MSMON_CFG_x_CTL_OFLOW_STATUS))
> + overflow_val = mpam_msmon_overflow_val(ris);
>
> mbwu_state->prev_val = now;
> mbwu_state->correction += overflow_val;
Thanks,
Ben
Powered by blists - more mailing lists