linux-kernel - Re: [PATCH v3 4/7] x86/resctrl: Re-arrange RFTYPE flags based on hierarchy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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