From: Ben Horgan <ben.horgan@arm.com>
To: Zeng Heng <zengheng4@huawei.com>, james.morse@arm.com
Cc: amitsinght@marvell.com, baisheng.gao@unisoc.com,
baolin.wang@linux.alibaba.com, carl@os.amperecomputing.com,
catalin.marinas@arm.com, dakr@kernel.org, dave.martin@arm.com,
david@redhat.com, dfustini@baylibre.com, fenghuay@nvidia.com,
gregkh@linuxfoundation.org, gshan@redhat.com,
guohanjun@huawei.com, jeremy.linton@arm.com,
jonathan.cameron@huawei.com, kobak@nvidia.com,
lcherian@marvell.com, lenb@kernel.org,
linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, lpieralisi@kernel.org,
peternewman@google.com, quic_jiles@quicinc.com,
rafael@kernel.org, robh@kernel.org, rohit.mathew@arm.com,
scott@os.amperecomputing.com, sdonthineni@nvidia.com,
sudeep.holla@arm.com, sunnanyong@huawei.com,
tan.shaopeng@fujitsu.com, wangkefeng.wang@huawei.com,
will@kernel.org, xhao@linux.alibaba.com
Subject: Re: [PATCH] arm64/mpam: Clean MBWU monitor overflow bit
Date: Tue, 28 Oct 2025 17:37:02 +0000 [thread overview]
Message-ID: <d91f65fb-900f-4d21-ad5e-0cbe146bbb65@arm.com> (raw)
In-Reply-To: <20251025093428.1379218-1-zengheng4@huawei.com>
Hi Zeng,
On 10/25/25 10:34, 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. Then, before updating the
> monitor configuration, the overflow bit should be cleared to zero.
>
> 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.
>
> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> ---
> drivers/resctrl/mpam_devices.c | 21 +++++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index 0dd048279e02..575980e3a366 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -1062,6 +1062,21 @@ static u64 mpam_msmon_overflow_val(enum mpam_device_features type)
> }
> }
>
> +static bool read_msmon_mbwu_is_overflow(struct mpam_msc *msc)
> +{
> + u32 ctl;
> + bool overflow;
> +
> + ctl = mpam_read_monsel_reg(msc, CFG_MBWU_CTL);
> + overflow = ctl & MSMON_CFG_x_CTL_OFLOW_STATUS ? true : false;
> +
> + if (overflow)
> + mpam_write_monsel_reg(msc, CFG_MBWU_CTL, ctl &
> + ~MSMON_CFG_x_CTL_OFLOW_STATUS);
Seems sensible. It's best to consider the overflow status bit for long
counters as well. Although, that's introduced later in the series so
depends on patch ordering. (Sorry, was considering patches on top of the
full series when I commented on counter length before.)
> +
> + return overflow;
> +}
> +
> /* Call with MSC lock held */
> static void __ris_msmon_read(void *arg)
> {
> @@ -1069,6 +1084,7 @@ static void __ris_msmon_read(void *arg)
> bool config_mismatch;
> struct mon_read *m = arg;
> u64 now, overflow_val = 0;
> + bool mbwu_overflow = false;
> struct mon_cfg *ctx = m->ctx;
> bool reset_on_next_read = false;
> struct mpam_msc_ris *ris = m->ris;
> @@ -1091,6 +1107,7 @@ static void __ris_msmon_read(void *arg)
> reset_on_next_read = mbwu_state->reset_on_next_read;
> mbwu_state->reset_on_next_read = false;
> }
> + mbwu_overflow = read_msmon_mbwu_is_overflow(msc);
If the config is then found to mismatch, then mbwu_overflow can be
subsequently set to false.
> }
>
> /*
> @@ -1138,8 +1155,8 @@ 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_overflow)
> + overflow_val = mpam_msmon_overflow_val(m->type);
Yep, makes sense.
>
> mbwu_state->prev_val = now;
With this prev_val no longer has any use.
> mbwu_state->correction += overflow_val;
Thanks,
Ben
next prev parent reply other threads:[~2025-10-28 17:37 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 18:56 [PATCH v3 00/29] arm_mpam: Add basic mpam driver James Morse
2025-10-17 18:56 ` [PATCH v3 01/29] ACPI / PPTT: Add a helper to fill a cpumask from a processor container James Morse
2025-10-24 11:26 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 02/29] ACPI / PPTT: Stop acpi_count_levels() expecting callers to clear levels James Morse
2025-10-24 11:29 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 03/29] ACPI / PPTT: Find cache level by cache-id James Morse
2025-10-20 10:34 ` Ben Horgan
2025-10-24 14:15 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 04/29] ACPI / PPTT: Add a helper to fill a cpumask from a cache_id James Morse
2025-10-20 10:45 ` Ben Horgan
2025-10-22 12:58 ` Jeremy Linton
2025-10-24 14:22 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 05/29] arm64: kconfig: Add Kconfig entry for MPAM James Morse
2025-10-17 18:56 ` [PATCH v3 06/29] ACPI / MPAM: Parse the MPAM table James Morse
2025-10-20 12:29 ` Ben Horgan
2025-10-24 16:13 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 07/29] arm_mpam: Add probe/remove for mpam msc driver and kbuild boiler plate James Morse
2025-10-20 12:43 ` Ben Horgan
2025-10-20 15:44 ` Ben Horgan
2025-10-21 9:51 ` Ben Horgan
2025-10-22 0:29 ` Fenghua Yu
2025-10-22 19:00 ` Tushar Dave
2025-10-24 16:25 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 08/29] arm_mpam: Add the class and component structures for firmware described ris James Morse
2025-10-24 16:47 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 09/29] arm_mpam: Add MPAM MSC register layout definitions James Morse
2025-10-17 23:03 ` Fenghua Yu
2025-10-24 17:32 ` Jonathan Cameron
2025-10-27 16:33 ` Ben Horgan
2025-10-29 6:37 ` Shaopeng Tan (Fujitsu)
2025-10-17 18:56 ` [PATCH v3 10/29] arm_mpam: Add cpuhp callbacks to probe MSC hardware James Morse
2025-10-29 7:24 ` Shaopeng Tan (Fujitsu)
2025-10-17 18:56 ` [PATCH v3 11/29] arm_mpam: Probe hardware to find the supported partid/pmg values James Morse
2025-10-24 17:40 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 12/29] arm_mpam: Add helpers for managing the locking around the mon_sel registers James Morse
2025-10-24 17:43 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 13/29] arm_mpam: Probe the hardware features resctrl supports James Morse
2025-10-24 17:47 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 14/29] arm_mpam: Merge supported features during mpam_enable() into mpam_class James Morse
2025-10-17 18:56 ` [PATCH v3 15/29] arm_mpam: Reset MSC controls from cpuhp callbacks James Morse
2025-10-24 17:52 ` Jonathan Cameron
2025-10-29 6:53 ` Shaopeng Tan (Fujitsu)
2025-10-17 18:56 ` [PATCH v3 16/29] arm_mpam: Add a helper to touch an MSC from any CPU James Morse
2025-10-17 18:56 ` [PATCH v3 17/29] arm_mpam: Extend reset logic to allow devices to be reset any time James Morse
2025-10-20 15:14 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 18/29] arm_mpam: Register and enable IRQs James Morse
2025-10-24 18:03 ` Jonathan Cameron
2025-10-29 7:02 ` Shaopeng Tan (Fujitsu)
2025-10-17 18:56 ` [PATCH v3 19/29] arm_mpam: Use a static key to indicate when mpam is enabled James Morse
2025-10-20 16:28 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 20/29] arm_mpam: Allow configuration to be applied and restored during cpu online James Morse
2025-10-20 17:04 ` Ben Horgan
2025-10-27 8:47 ` Shaopeng Tan (Fujitsu)
2025-10-29 7:09 ` Shaopeng Tan (Fujitsu)
2025-10-17 18:56 ` [PATCH v3 21/29] arm_mpam: Probe and reset the rest of the features James Morse
2025-10-20 17:16 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 22/29] arm_mpam: Add helpers to allocate monitors James Morse
2025-10-17 18:56 ` [PATCH v3 23/29] arm_mpam: Add mpam_msmon_read() to read monitor value James Morse
2025-10-24 18:18 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 24/29] arm_mpam: Track bandwidth counter state for overflow and power management James Morse
2025-10-22 13:39 ` [PATCH mpam mpam/snapshot/v6.14-rc1] arm64/mpam: Fix MBWU monitor overflow handling Zeng Heng
2025-10-22 16:17 ` Ben Horgan
2025-10-25 8:45 ` Zeng Heng
2025-10-25 9:34 ` [PATCH] arm64/mpam: Clean MBWU monitor overflow bit Zeng Heng
2025-10-28 17:37 ` Ben Horgan [this message]
2025-10-28 17:04 ` [PATCH mpam mpam/snapshot/v6.14-rc1] arm64/mpam: Fix MBWU monitor overflow handling Ben Horgan
2025-10-25 9:01 ` Zeng Heng
2025-10-28 16:01 ` Ben Horgan
2025-10-29 2:49 ` Zeng Heng
2025-10-29 3:59 ` Zeng Heng
2025-10-24 18:22 ` [PATCH v3 24/29] arm_mpam: Track bandwidth counter state for overflow and power management Jonathan Cameron
2025-10-29 7:56 ` [PATCH v2] arm64/mpam: Clean MBWU monitor overflow bit Zeng Heng
2025-10-30 9:52 ` Ben Horgan
2025-10-17 18:56 ` [PATCH v3 25/29] arm_mpam: Probe for long/lwd mbwu counters James Morse
2025-10-22 11:23 ` Ben Horgan
2025-10-24 18:24 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 26/29] arm_mpam: Use long MBWU counters if supported James Morse
2025-10-22 12:31 ` Ben Horgan
2025-10-24 18:29 ` Jonathan Cameron
2025-10-17 18:56 ` [PATCH v3 27/29] arm_mpam: Add helper to reset saved mbwu state James Morse
2025-10-24 18:34 ` Jonathan Cameron
2025-10-29 7:14 ` Shaopeng Tan (Fujitsu)
2025-10-17 18:56 ` [PATCH v3 28/29] arm_mpam: Add kunit test for bitmap reset James Morse
2025-10-17 18:56 ` [PATCH v3 29/29] arm_mpam: Add kunit tests for props_mismatch() James Morse
2025-10-18 1:01 ` [PATCH v3 00/29] arm_mpam: Add basic mpam driver Fenghua Yu
2025-10-23 8:15 ` Shaopeng Tan (Fujitsu)
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=d91f65fb-900f-4d21-ad5e-0cbe146bbb65@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=catalin.marinas@arm.com \
--cc=dakr@kernel.org \
--cc=dave.martin@arm.com \
--cc=david@redhat.com \
--cc=dfustini@baylibre.com \
--cc=fenghuay@nvidia.com \
--cc=gregkh@linuxfoundation.org \
--cc=gshan@redhat.com \
--cc=guohanjun@huawei.com \
--cc=james.morse@arm.com \
--cc=jeremy.linton@arm.com \
--cc=jonathan.cameron@huawei.com \
--cc=kobak@nvidia.com \
--cc=lcherian@marvell.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=peternewman@google.com \
--cc=quic_jiles@quicinc.com \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=rohit.mathew@arm.com \
--cc=scott@os.amperecomputing.com \
--cc=sdonthineni@nvidia.com \
--cc=sudeep.holla@arm.com \
--cc=sunnanyong@huawei.com \
--cc=tan.shaopeng@fujitsu.com \
--cc=wangkefeng.wang@huawei.com \
--cc=will@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;
as well as URLs for NNTP newsgroup(s).