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

From: Reinette Chatre
Date: Wed Mar 15 2023 - 14:40:12 EST


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

...

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