Hi Reinette,
To be honest, I had tough time understanding these flags. Also, I need to
add more files in the future. So, I am trying make these these things
clear before I do those changes.
These flags decoding is pretty confusing. Also, there are some flags which
are duplicate. Not really required.
For example:
In group structure, we have control group or mon group. We just need two
bits here. The code uses combination of 3 flags here.
#define RFTYPE_BASE BIT(1)
#define RFTYPE_CTRL BIT(4)
#define RFTYPE_MON BIT(5)
Also, the flag RFTYPE_MON again used in creation on info directory.
Basically, very confusing to add anything new.
I will try to minimize the changes in the next version but still make it
clear.
On 3/15/23 13:37, Reinette Chatre wrote:
> Hi Babu,
>
> On 3/2/2023 12:24 PM, Babu Moger wrote:
>> RESCTRL filesystem has two main components:
>> a. info (Details on resources and monitoring)
>> b. base (Details on CONTROL and MON groups)
>>
>> The rftype flags can be renamed accordingly for better understanding.
>> For example:
>> RFTYPE_INFO : Files with these flags go in info directory
>
> This is not a rename but the current name.
Agree. I am giving some example here. I may not need to change the text here.
>
>> RFTYPE_INFO_MON : Files with these flags go in info/L3_MON
>
> How does this improve the current RFTYPE_MON_INFO?
RFTYPE_INFO_MON -> info/L3_MON.
I tried to improve some readability based on hierarchy. Basically, looking
at the flags we know exaclty where these files land.
>
>> RFTYPE_BASE : Files with these flags go in group's(control or mon)
>> base directory
> This is not a rename but the current name.
>
>> RFTYPE_BASE_CTRL: Files with these flags go in only CONTROL groups
>
> How does this improve current RFTYPE_CTRL_BASE ?
Again, same explanation as above. Started with RFTYPE_BASE and added
RFTYPE_BASE_CTRL to say these files are on top of base.
>
>>
>> Add comments to make it easy for future additions.
>>
>> Signed-off-by: Babu Moger <babu.moger@xxxxxxx>
>> ---
>> arch/x86/kernel/cpu/resctrl/core.c | 8 ++--
>> arch/x86/kernel/cpu/resctrl/internal.h | 64 ++++++++++++++++++++++++++++----
>> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 44 +++++++++++-----------
>> 3 files changed, 81 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
>> index 030d3b409768..d1c6b2cc8611 100644
>> --- a/arch/x86/kernel/cpu/resctrl/core.c
>> +++ b/arch/x86/kernel/cpu/resctrl/core.c
>> @@ -69,7 +69,7 @@ struct rdt_hw_resource rdt_resources_all[] = {
>> .domains = domain_init(RDT_RESOURCE_L3),
>> .parse_ctrlval = parse_cbm,
>> .format_str = "%d=%0*x",
>> - .fflags = RFTYPE_RES_CACHE,
>> + .fflags = RFTYPE_CACHE,
>> },
>
> How does this rename improve understanding?
Agree. This change may not be required. I can actually remove these changes
>
> ...
>
>> @@ -97,7 +97,7 @@ struct rdt_hw_resource rdt_resources_all[] = {
>> .domains = domain_init(RDT_RESOURCE_MBA),
>> .parse_ctrlval = parse_bw,
>> .format_str = "%d=%*u",
>> - .fflags = RFTYPE_RES_MB,
>> + .fflags = RFTYPE_MB,
>> },
>> },
>> [RDT_RESOURCE_SMBA] =
>
> ditto.
Agree. This change may not be required. I can actually remove these changes
.
>
>
> ...
>
>> + *
>> */
>> #define RFTYPE_INFO BIT(0)
>> #define RFTYPE_BASE BIT(1)
>> -#define RFTYPE_CTRL BIT(4)
>> -#define RFTYPE_MON BIT(5)
>> -#define RFTYPE_TOP BIT(6)
>> -#define RFTYPE_RES_CACHE BIT(8)
>> -#define RFTYPE_RES_MB BIT(9)
>> -#define RFTYPE_CTRL_INFO (RFTYPE_INFO | RFTYPE_CTRL)
>> -#define RFTYPE_MON_INFO (RFTYPE_INFO | RFTYPE_MON)
>> -#define RFTYPE_TOP_INFO (RFTYPE_INFO | RFTYPE_TOP)
>> -#define RFTYPE_CTRL_BASE (RFTYPE_BASE | RFTYPE_CTRL)
>> +
>> +#define RFTYPE_TOP BIT(2)
>> +#define RFTYPE_MON BIT(3)
>> +#define RFTYPE_RES BIT(4)
>> +
>> +#define RFTYPE_CACHE BIT(5)
>> +#define RFTYPE_MB BIT(6)
>> +
>> +#define RFTYPE_CTRL BIT(8)
>> +
>> +#define RFTYPE_INFO_TOP (RFTYPE_INFO | RFTYPE_TOP)
>> +#define RFTYPE_INFO_MON (RFTYPE_INFO | RFTYPE_MON)
>> +#define RFTYPE_INFO_RES (RFTYPE_INFO | RFTYPE_RES)
>> +
>> +#define RFTYPE_BASE_CTRL (RFTYPE_BASE | RFTYPE_CTRL)
>>
>
> It is not clear to me how any of the renames improves understanding.
>
> How does renaming RFTYPE_CTRL_BASE to RFTYPE_BASE_CTRL improve
> understanding? Renaming RFTYPE_MON_INFO to RFTYPE_INFO_MON?
>
> This all seems unnecessary.
Again see my comments in the beginning.
>
> ...
>
>> @@ -3218,7 +3218,7 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn,
>> if (rtype == RDTCTRL_GROUP)
>> fflags = RFTYPE_BASE | RFTYPE_CTRL;
>> else
>> - fflags = RFTYPE_BASE | RFTYPE_MON;
>> + fflags = RFTYPE_BASE;
>>
>
> Is this intended?
Yes. We don't need this extra flag (RFTYPE_MON) here.
Thanks
Babu Moger
