Hi Dave, On 5/3/2024 7:53 AM, Dave Martin wrote: > On Thu, May 02, 2024 at 10:52:15AM -0700, Reinette Chatre wrote: >> Hi Dave, >> >> On 5/2/2024 9:21 AM, Dave Martin wrote: >>> On Thu, Mar 28, 2024 at 08:06:50PM -0500, Babu Moger wrote: >>>> diff --git a/Documentation/arch/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst >>>> index 2d96565501ab..64ec70637c66 100644 >>>> --- a/Documentation/arch/x86/resctrl.rst >>>> +++ b/Documentation/arch/x86/resctrl.rst >>>> @@ -328,6 +328,77 @@ with the following files: >>>> None of events are assigned on this mon group. This is a child >>>> monitor group of the non default control mon group. >>>> >>>> + Assignment state can be updated by writing to this interface. >>>> + >>>> + NOTE: Assignment on one domain applied on all the domains. User can >>>> + pass one valid domain and assignment will be updated on all the >>>> + available domains. >>>> + >>>> + Format is similar to the list format with addition of op-code for the >>>> + assignment operation. >>>> + >>>> + * Default CTRL_MON group: >>>> + "//<domain_id><op-code><assignment_flags>" >>>> + >>>> + * Non-default CTRL_MON group: >>>> + "<CTRL_MON group>//<domain_id><op-code><assignment_flags>" >>>> + >>>> + * Child MON group of default CTRL_MON group: >>>> + "/<MON group>/<domain_id><op-code><assignment_flags>" >>>> + >>>> + * Child MON group of non-default CTRL_MON group: >>>> + "<CTRL_MON group>/<MON group>/<domain_id><op-code><assignment_flags>" >>> >>> The final bullet seems to cover everything, if we allow <CTRL_MON group> >>> and <MON group> to be independently empty strings to indicate the >>> default control and/or monitoring group respectively. >>> >>> Would that be simpler than treating this as four separate cases? >>> >>> Also, will this go wrong if someone creates a resctrl group with '\n' >>> (i.e., a newline character) in the name? >> >> There is a check for this in rdtgroup_mkdir(). > > Ah, right. Found it. I guess that works. > > On a (sort of) related point, are there any concerns about namespace > clashes in resctrlfs? This looks like a potential issue for the resctrl > top-level directory at least. > > It's not clear to me how userspace can pick a name for a resctrl group > that is guaranteed not to clash with the name of one of resctrl's own > files in a future kernel. > > (Note, this is nothing to do with series; I haven't been sure where to > fit this into the dicsussion...) It is not obvious to me what scenario you have in mind. Could you please give an example? > >> >>> >>>> + >>>> + Op-code can be one of the following: >>>> + :: >>>> + >>>> + = Update the assignment to match the flags >>>> + + Assign a new state >>>> + - Unassign a new state >>>> + _ Unassign all the states >>> >>> I can't remember whether I already asked this, but is "_" really >>> needed here? >> >> Asked twice: >> https://lore.kernel.org/lkml/ZiaRXrmDDjc194JI@xxxxxxxxxxxxxxx/ >> https://lore.kernel.org/lkml/ZiervIprcwoApAqw@xxxxxxxxxxxxxxx/ >> >> Answered: >> https://lore.kernel.org/lkml/4cd220cc-2e8e-4193-b01a-d3cd798c7118@xxxxxxx/ >> >> You seemed ok with answer then: >> https://lore.kernel.org/lkml/ZiffF93HM8bE3qo7@xxxxxxxxxxxxxxx/ > > There, I was asking about "_" meaning "no flags" in "=_". Apologies. I did not notice the difference. Yes, I agree, "_" is not expected to be an operator. Reinette
