[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c083cfb4-3282-2aeb-c704-9cc21ada918e@amd.com>
Date: Tue, 21 Mar 2023 10:54:48 -0500
From: "Moger, Babu" <babu.moger@....com>
To: Reinette Chatre <reinette.chatre@...el.com>, corbet@....net,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de
Cc: fenghua.yu@...el.com, dave.hansen@...ux.intel.com, x86@...nel.org,
hpa@...or.com, paulmck@...nel.org, akpm@...ux-foundation.org,
quic_neeraju@...cinc.com, rdunlap@...radead.org,
damien.lemoal@...nsource.wdc.com, songmuchun@...edance.com,
peterz@...radead.org, jpoimboe@...nel.org, pbonzini@...hat.com,
chang.seok.bae@...el.com, pawan.kumar.gupta@...ux.intel.com,
jmattson@...gle.com, daniel.sneddon@...ux.intel.com,
sandipan.das@....com, tony.luck@...el.com, james.morse@....com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
bagasdotme@...il.com, eranian@...gle.com,
christophe.leroy@...roup.eu, jarkko@...nel.org,
adrian.hunter@...el.com, quic_jiles@...cinc.com,
peternewman@...gle.com
Subject: Re: [PATCH v3 4/7] x86/resctrl: Re-arrange RFTYPE flags based on
hierarchy
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@....com>
>> ---
>> 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
Powered by blists - more mailing lists