Re: [PATCH v4 7/7] x86/resctrl: Add debug files when mounted with debug option

Moger, Babu
2023-04-19T15:20:31Z

On 4/19/23 08:20, Ilpo Järvinen wrote:
> On Mon, 17 Apr 2023, Babu Moger wrote:
>
>> Add the debug files to the resctrl hierarchy.
>>
>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>> ---
>> arch/x86/kernel/cpu/resctrl/internal.h | 1 +
>> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 54 +++++++++++++++++++++++++++++++-
>> 2 files changed, 54 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
>> index 1eac07ebc31b..855109abb480 100644
>> --- a/arch/x86/kernel/cpu/resctrl/internal.h
>> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
>> @@ -288,6 +288,7 @@ struct rdtgroup {
>> #define RFTYPE_TOP BIT(4)
>> #define RFTYPE_RES_CACHE BIT(5)
>> #define RFTYPE_RES_MB BIT(6)
>> +#define RFTYPE_DEBUG BIT(7)
>> #define RFTYPE_CTRL_INFO (RFTYPE_INFO | RFTYPE_CTRL)
>> #define RFTYPE_MON_INFO (RFTYPE_INFO | RFTYPE_MON)
>> #define RFTYPE_TOP_INFO (RFTYPE_INFO | RFTYPE_TOP)
>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> index 15ded0dd5b09..1ec4359348c2 100644
>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> @@ -1880,6 +1880,7 @@ static struct rftype res_common_files[] = {
>> .mode = 0444,
>> .kf_ops = &rdtgroup_kf_single_ops,
>> .seq_show = rdtgroup_rmid_show,
>> + .fflags = RFTYPE_BASE | RFTYPE_DEBUG,
>> },
>> {
>> .name = "schemata",
>> @@ -1909,6 +1910,7 @@ static struct rftype res_common_files[] = {
>> .mode = 0444,
>> .kf_ops = &rdtgroup_kf_single_ops,
>> .seq_show = rdtgroup_closid_show,
>> + .fflags = RFTYPE_CTRL_BASE | RFTYPE_DEBUG,
>> },
>>
>> };
>> @@ -2420,6 +2422,49 @@ static int mkdir_mondata_all(struct kernfs_node *parent_kn,
>> struct rdtgroup *prgrp,
>> struct kernfs_node **mon_data_kn);
>>
>> +static void resctrl_add_debug_files(void)
>> +{
>> + struct rftype *rfts, *rft;
>> + int len;
>> +
>> + rfts = res_common_files;
>> + len = ARRAY_SIZE(res_common_files);
>> +
>> + lockdep_assert_held(&rdtgroup_mutex);
>> +
>> + for (rft = rfts; rft < rfts + len; rft++) {
>> + if (rft->fflags & RFTYPE_DEBUG) {
>> + rft->fflags &= ~RFTYPE_DEBUG;
>
> I don't fully follow why you need to play with ->fflags like this.

Yes. It is because of this check.
if (rft->fflags && ((fflags & rft->fflags) == rft->fflags)) {

I am not sure about "== rft->fflags" check. If I remove this check then I
may not have to do all this trick. I can try that.

> Is it for the ->fflags test in rdtgroup_add_files()? Can't you just do
> some extra masking there for RFTYPE_DEBUG based on resctrl_debug which
> you already keep?

Yes. Let me experiment little bit.
Thanks
Babu
>
>> + rdtgroup_add_file(rdtgroup_default.kn, rft);
>> + }
>> + }
>> +
>> + kernfs_activate(rdtgroup_default.kn);
>> +}
>> +
>> +static void resctrl_remove_debug_files(void)
>> +{
>> + struct rftype *rfts, *rft;
>> + int len;
>> +
>> + rfts = res_common_files;
>> + len = ARRAY_SIZE(res_common_files);
>> +
>> + lockdep_assert_held(&rdtgroup_mutex);
>> +
>> + for (rft = rfts; rft < rfts + len; rft++) {
>> + if (!strcmp(rft->name, "mon_hw_id")) {
>> + rft->fflags |= RFTYPE_DEBUG;
>> + kernfs_remove_by_name(rdtgroup_default.kn, rft->name);
>> + } else if (!strcmp(rft->name, "ctrl_hw_id")) {
>> + rft->fflags |= RFTYPE_DEBUG;
>> + kernfs_remove_by_name(rdtgroup_default.kn, rft->name);
>> + }
>> + }
>> +
>> + kernfs_activate(rdtgroup_default.kn);
>> +}
>> +
>> static int rdt_enable_ctx(struct rdt_fs_context *ctx)
>> {
>> int ret = 0;
>> @@ -2433,8 +2478,10 @@ static int rdt_enable_ctx(struct rdt_fs_context *ctx)
>> if (!ret && ctx->enable_mba_mbps)
>> ret = set_mba_sc(true);
>>
>> - if (!ret && ctx->enable_debug)
>> + if (!ret && ctx->enable_debug) {
>> resctrl_debug = true;
>> + resctrl_add_debug_files();
>> + }
>>
>> return ret;
>> }
>> @@ -2851,6 +2898,11 @@ static void rdt_kill_sb(struct super_block *sb)
>>
>> set_mba_sc(false);
>>
>> + if (resctrl_debug) {
>> + resctrl_remove_debug_files();
>> + resctrl_debug = false;
>
> Logically, this false assignment belongs to the earlier patch.
>

--
Thanks
Babu Moger