Messages in this thread | | | Date | Tue, 8 Nov 2022 23:57:57 +0800 | From | Shawn Wang <> | Subject | Re: [PATCH 06/18] x86/resctrl: Allow the allocator to check if a CLOSID can allocate clean RMID |
| |
Hi James,
On 10/21/2022 9:11 PM, James Morse wrote: > MPAM's PMG bits extend its PARTID space, meaning the same PMG value can be > used for different control groups. > > This means once a CLOSID is allocated, all its monitoring ids may still be > dirty, and held in limbo. > > Add a helper to allow the CLOSID allocator to check if a CLOSID has dirty > RMID values. This behaviour is enabled by a kconfig option selected by > the architecture, which avoids a pointless search for x86. > > Signed-off-by: James Morse <james.morse@arm.com> > --- > arch/x86/kernel/cpu/resctrl/internal.h | 1 + > arch/x86/kernel/cpu/resctrl/monitor.c | 31 ++++++++++++++++++++++++++ > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 18 +++++++++------ > 3 files changed, 43 insertions(+), 7 deletions(-)
> +/** > + * resctrl_closid_is_dirty - Determine if clean RMID can be allocate for this > + * CLOSID. > + * @closid: The CLOSID that is being queried. > + * > + * MPAM's equivalent of RMID are per-CLOSID, meaning a freshly allocate CLOSID > + * may not be able to allocate clean RMID. To avoid this the allocator will > + * only return clean CLOSID. > + */ > +bool resctrl_closid_is_dirty(u32 closid) > +{ > + struct rmid_entry *entry; > + int i; > + > + lockdep_assert_held(&rdtgroup_mutex); > + > + if (IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID)) > + return false;
Since dirty closid occurs when the kconfig option for MPAM is enabled, it seems that the condition of the if statement here should take the opposite value: if (!IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID))
> + > + for (i = 0; i < resctrl_arch_system_num_rmid_idx(); i++) { > + entry = &rmid_ptrs[i]; > + if (entry->closid != closid) > + continue; > + > + if (entry->busy) > + return true; > + } > + > + return false; > +} > +
Shawn
| |