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: <26400c6a-dcde-9ac2-df7a-117a12875f0c@intel.com>
Date:   Wed, 15 Mar 2023 11:37:40 -0700
From:   Reinette Chatre <reinette.chatre@...el.com>
To:     Babu Moger <babu.moger@....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 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.

> RFTYPE_INFO_MON : Files with these flags go in info/L3_MON

How does this improve the current RFTYPE_MON_INFO?

> 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 ?

> 
> 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?

...

> @@ -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.


...

> + *
>   */
>  #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.

...

> @@ -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?

Reinette