Re: [PATCH v3 00/12] [PATCH v3 00/12] x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem

[Reinette Chatre]

Hi Babu,

On 4/30/26 4:24 PM, Babu Moger wrote:
> Design
> ======
> 
> A new sysfs file, info/kernel_mode, holds a single global policy that
> selects what kernel work is steered and which rdtgroup it is steered

How should "selects *what* kernel work is steered" be interpreted? Do these
modes not all apply to *all* kernel work? 

> to.  Reads describe the supported modes and the currently-active
> binding; writes change the policy or rebind to a different group.
> Look at the thread below for design discussion.
> https://lore.kernel.org/lkml/14a8ad0a-e842-4268-871a-0762f1169e03@xxxxxxxxx/
> 

...

> Examples
> ========
> 
> (See Documentation/filesystems/resctrl.rst, "kernel_mode" and
> "kmode_cpus" sections, for the full UAPI.)
> 
>   # Mount resctrl
>   # mount -t resctrl resctrl /sys/fs/resctrl
>   # cd /sys/fs/resctrl
> 
>   # Read the supported modes.  The active mode is bracketed and reports
>   # the bound "<ctrl>/<mon>/" group; other supported modes report
>   # ":group=none" because nothing is bound to them.
>   # cat info/kernel_mode
>   [inherit_ctrl_and_mon:group=//]

This is unexpected since associating a group to this mode implies that this
group is used to manage allocations and monitoring of kernel work but this
is not true, right? From what I understand there should be no group associated with
this default "inherit_ctrl_and_mon" mode. 

>   global_assign_ctrl_inherit_mon_per_cpu:group=none
>   global_assign_ctrl_assign_mon_per_cpu:group=none

nit: "none" does not reflect state as clearly as "unset"/"uninitialized"/"NA" 

> 
>   # Create a CTRL_MON group plus a MON child and bind both the kernel
>   # CLOSID and RMID to them.
>   # mkdir ctrl1
>   # mkdir ctrl1/mon_groups/mon1
>   # echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/" \
>           > info/kernel_mode
>   # cat info/kernel_mode
>   inherit_ctrl_and_mon:group=none
>   global_assign_ctrl_inherit_mon_per_cpu:group=none
>   [global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/]
> 
>   # kmode_cpus and kmode_cpus_list are visible only on the bound group.
>   # ls ctrl1/kmode_cpus*
>   ctrl1/kmode_cpus  ctrl1/kmode_cpus_list

Since it is ctrl1/mon1 that was bound, should these CPU files not appear
in ctrl1/mon_groups/mon1 ?

> 
>   # Restrict the binding to a CPU subset; the write is incremental.

Does "incremental" mean that if the file contains CPUs 0-3 then writing
"4" would set the CPUs to 0-4? This does not sound right since it is
expected that user space can remove CPUs also?

>   # echo 0-3 > ctrl1/kmode_cpus_list
>   # cat ctrl1/kmode_cpus
>   f
>   # cat ctrl1/kmode_cpus_list
>   0-3
> 
>   # Empty masks are rejected; use info/kernel_mode to reset to
>   # "every online CPU".
>   # echo "" > ctrl1/kmode_cpus_list
>   bash: echo: write error: Invalid argument
>   # cat info/last_cmd_status
>   Empty mask not allowed; use info/kernel_mode to unbind

Why are empty masks rejected/not allowed?

> 
>   # Disable kernel-mode steering (back to inherit, default group).

This sounds like kernel work is steered to default group which I 
do not think is accurate for the "inherit_ctrl_and_mon" mode.

>   # echo "inherit_ctrl_and_mon" > info/kernel_mode
> 
> Tested on AMD with PLZA; the generic bits build clean on x86 without
> PLZA support and are no-ops at runtime.

Reinette