Re: [PATCH v10 06/17] x86/resctrl: Drop global 'rdt_mon_capable' flag

[Reinette Chatre]

Hi Tony,

On 7/29/26 10:27 AM, Tony Luck wrote:
> File system code calls resctrl_arch_mon_capable() to determine if the
> system supports any monitoring features.
> 
> x86 architecture code sets a global flag to support implementation of
> resctrl_arch_mon_capable() but the upcoming change to enumerate AET
> (Application Energy Telemetry) features on each mount introduces a new
> corner case.
> 
> Specifically when AET is the only monitoring feature, loading and
> unloading the pmt_telemetry module between resctrl mounts may result
> in monitoring support enabled on some mounts, but not on others.
> 
> Replace the global flag with a scan of resources to check if any are
> marked mon_capable.
> 
> Signed-off-by: Tony Luck <tony.luck@xxxxxxxxx>
> ---
> v10:
> 	Move declaration of resctrl_arch_mon_capable() to <linux/resctrl.h>
> 	and provide kerneldoc comment on usage.
> 
>  include/linux/arm_mpam.h              |  1 -
>  include/linux/resctrl.h               | 17 +++++++++++++++++
>  arch/x86/include/asm/resctrl.h        |  6 ------
>  arch/x86/kernel/cpu/resctrl/core.c    | 19 ++++++++++++++++---
>  arch/x86/kernel/cpu/resctrl/monitor.c |  6 ------

Note that this patch changes MPAM, resctrl fs, as well as x86 while
the subject prefix just mentions x86.

>  5 files changed, 33 insertions(+), 16 deletions(-)
> 
> diff --git a/include/linux/arm_mpam.h b/include/linux/arm_mpam.h
> index f92a36187a52..b6e8683657c0 100644
> --- a/include/linux/arm_mpam.h
> +++ b/include/linux/arm_mpam.h
> @@ -51,7 +51,6 @@ static inline int mpam_ris_create(struct mpam_msc *msc, u8 ris_idx,
>  #endif
>  
>  bool resctrl_arch_alloc_capable(void);
> -bool resctrl_arch_mon_capable(void);
>  
>  void resctrl_arch_set_cpu_default_closid(int cpu, u32 closid);
>  void resctrl_arch_set_closid_rmid(struct task_struct *tsk, u32 closid, u32 rmid);
> diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
> index a184500745f8..59ddedb27539 100644
> --- a/include/linux/resctrl.h
> +++ b/include/linux/resctrl.h
> @@ -419,6 +419,23 @@ u32 resctrl_arch_get_num_closid(struct rdt_resource *r);
>  u32 resctrl_arch_system_num_rmid_idx(void);
>  int resctrl_arch_update_domains(struct rdt_resource *r, u32 closid);
>  
> +/**
> + * resctrl_arch_mon_capable() - Report whether monitor events are enabled
> + *
> + * Some monitor events may be enumerated or implemented in loadable modules.
> + * This means that available events may vary from one mount of the resctrl
> + * file system to another. If modules are not loaded at mount time there
> + * may be no monitor events at all.

I do not see how this is relevant to the API documentation. Please just focus on
the contract between resctrl fs and architecture. Looks like this is information that
can be provided in the x86 implementation of this callback. It is not guidance to
all architectures.

> + *
> + * File system code may call it during mount after architecture enumeration is

There cannot be any "may". This needs to be a contract where it is clear to
architecture when resctrl fs can be expected to call this and what the expected
return should be. For example, resctrl fs calls this during a mount cycle and
architecture has to provide the same value during the entire mount cycle.

> + * complete. Calls during domain add/remove operations must check resctrl_mounted

Not possible. resctrl_mounted is internal to resctrl fs so architecture has no
insight into this. The guidance to "must check" is not useful, as in, what should
be checked for? That it is mounted, that it is not mounted? How does domain
add/remove apply here?

> + * before calling.
> + *
> + * Return:
> + * true if any monitor events are enabled in the current mount cycle.
> + */
> +bool resctrl_arch_mon_capable(void);
> +
>  /**
>   * resctrl_enable_mon_event() - Enable monitoring event
>   * @eventid:	ID of the event
Reinette