Messages in this thread | | | Date | Fri, 3 Mar 2023 18:33:57 +0000 | Subject | Re: [PATCH v2 04/18] x86/resctrl: Move rmid allocation out of mkdir_rdt_prepare() | From | James Morse <> |
| |
Hi Reinette,
On 02/02/2023 23:45, Reinette Chatre wrote: > On 1/13/2023 9:54 AM, James Morse wrote: >> RMID are allocated for each monitor or control group directory, because >> each of these needs its own RMID. For control groups, >> rdtgroup_mkdir_ctrl_mon() later goes on to allocate the CLOSID. >> >> MPAM's equivalent of RMID are not an independent number, so can't be >> allocated until the closid is known. An RMID allocation for one CLOSID
> Could you please be consistent with CLOSID vs closid (also RMID vs rmid)? > When reading through the series and seeing the switch it is not clear if > text refers to same concept.
Yup, I'm trying, but there will be some that slip through.
>> may fail, whereas another may succeed depending on how many monitor >> groups a control group has. >> >> The RMID allocation needs to move to be after the CLOSID has been >> allocated. >> >> Move the RMID allocation out of mkdir_rdt_prepare() to occur in its caller, >> after the mkdir_rdt_prepare() call. This allows the RMID allocator to >> know the CLOSID.
>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> index 841294ad6263..c67083a8a5f5 100644 >> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c >> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> @@ -2957,10 +2963,6 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn, >> goto out_destroy; >> } >> >> - ret = mkdir_rdt_prepare_rmid_alloc(rdtgrp); >> - if (ret) >> - goto out_destroy; >> - >> kernfs_activate(kn); >> > > This moves the creation of the monitoring related files/directories to later, but leaves > the kernfs_activate() that activates the node and make it visible to user space. Should > this activation be moved?
I hadn't properly grasped what that was doing Yes, I've moved it to after the mkdir_rdt_prepare_rmid_alloc() calls in the two callers.
Thanks,
James
| |