Messages in this thread |  | | From | Peter Newman <> | | Date | Thu, 4 Jan 2024 11:13:35 -0800 | | Subject | Re: [PATCH v8 08/24] x86/resctrl: Track the number of dirty RMID a CLOSID has |
| |
Hi James,
On Fri, Dec 15, 2023 at 9:44 AM James Morse <james.morse@arm.com> wrote: > 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 = resctrl_arch_system_num_rmid_idx(); > + u32 num_closid = 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=mpam/snapshot/v6.7-rc2&id=a0ab3a6c26002
|  |