Received-SPF: pass (google.com: domain of linux-kernel+bounces-17137-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20231215174343.13872-1-james.morse@arm.com> <20231215174343.13872-9-james.morse@arm.com>
In-Reply-To: <20231215174343.13872-9-james.morse@arm.com>
From: Peter Newman <peternewman@google.com>
Date: Thu, 4 Jan 2024 11:13:35 -0800
Message-ID: <CALPaoCi_3aPQ1cebtJLtnNEGjiAX8WjJcHP008wAOh0h+O=trQ@mail.gmail.com>
Subject: Re: [PATCH v8 08/24] x86/resctrl: Track the number of dirty RMID a
 CLOSID has
To: James Morse <james.morse@arm.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, 
	Fenghua Yu <fenghua.yu@intel.com>, Reinette Chatre <reinette.chatre@intel.com>, 
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	H Peter Anvin <hpa@zytor.com>, Babu Moger <Babu.Moger@amd.com>, shameerali.kolothum.thodi@huawei.com, 
	D Scott Phillips OS <scott@os.amperecomputing.com>, carl@os.amperecomputing.com, 
	lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, 
	baolin.wang@linux.alibaba.com, Jamie Iles <quic_jiles@quicinc.com>, 
	Xin Hao <xhao@linux.alibaba.com>, dfustini@baylibre.com, amitsinght@marvell.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi James,

On Fri, Dec 15, 2023 at 9:44=E2=80=AFAM James Morse <james.morse@arm.com> w=
rote:
>  void free_rmid(u32 closid, u32 rmid)
> @@ -792,13 +813,33 @@ void mbm_setup_overflow_handler(struct rdt_domain *=
dom, unsigned long delay_ms)
>  static int dom_data_init(struct rdt_resource *r)
>  {
>         u32 idx_limit =3D resctrl_arch_system_num_rmid_idx();
> +       u32 num_closid =3D resctrl_arch_get_num_closid(r);

Which resource is this again? Surely the one with the smallest number
of CLOSIDs?

It's not much harm if the array is bigger than it needs to be, but
I've become curious about how The Monitoring Resource is used in the
code when there are later changes[1] which would cause this function
to be called on RDT_RESOURCE_L3, RDT_RESOURCE_MBA, or both.

Given that we have hardware with event counters residing at different
levels of the topology and possibly being associated with different
rdt_resources, more attention needs to be paid to how these parameters
are used in code related to monitoring.

-Peter

[1] https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/commit/=
drivers/platform/mpam/mpam_resctrl.c?h=3Dmpam/snapshot/v6.7-rc2&id=3Da0ab3a=
6c26002