Messages in this thread | | | Date | Wed, 9 Nov 2022 17:02:40 +0000 | Subject | Re: [PATCH 06/18] x86/resctrl: Allow the allocator to check if a CLOSID can allocate clean RMID | From | James Morse <> |
| |
Hi Shawn,
On 08/11/2022 15:57, Shawn Wang wrote: > 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.
>> +/** >> + * 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))
Yup. Bother.
Thanks for spotting that! It was intended to avoid this work on x86 as its pointless, and the number of RMID could be large.
Thanks!
James
| |