Hi Ben,
On 3/26/26 10:25 AM, Ben Horgan wrote:
> When 0 is written to the tasks file it is interpreted as the current task
> in rdtgroup_move_task(). The task_struct for each CPUs idle task has pid
"each CPUs" -> "each CPU's"
"pid" could be PID or task_struct::pid to help make clear what it refers to.
> set to 0 and, on x86, the closid to RESCTRL_RESERVED_CLOSID and rmid to
It is not clear if you refer to the actual task_struct field, for example
task_struct::closid, or what it represents, for example CLOSID.
> RESCTRL_RESERVED_RMID. Equivalently, on MPAM platforms,
> thread_info->mpam_partid_pmg is encoded with PARTID and PMG set to
thread_info->mpam_partid_pmg to thread_info::mpam_partid_pmg to be consistent
if making an earlier change.
> RESCTRL_RESERVED_CLOSID and RESCTRL_RESERVED_RMID, respectively. As there
> is no interface to change these from the default, the resctrl configuration
> for the idle tasks is fixed and they always behave equivalently to a task
> in the default tasks file and so take their configuration from the cpus
"cpus" -> "cpus/cpus_list"
> files.
>
> On read of the tasks file, show_rdt_tasks() filters out any 0 pid. Hence,
"pid" -> "PID"
> a task id of 0 is never shown in the tasks file and the idle tasks are
> not represented either.
>
> Document the user visible behaviour.
>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> I have confirmed this experimentally on an MPAM platform.
> ---
> Documentation/filesystems/resctrl.rst | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
> index 68cada238844..3ec6b3b1b603 100644
> --- a/Documentation/filesystems/resctrl.rst
> +++ b/Documentation/filesystems/resctrl.rst
> @@ -568,6 +568,11 @@ All groups contain the following files:
> then the task must already belong to the CTRL_MON parent of this
> group. The task is removed from any previous MON group.
>
> + When writing to this file, a task id of 0 is interpreted as the
> + task id of the currently running task. On reading the file, a task
> + id of 0 will never be shown and there is no representation of the
> + idle tasks. Instead, a CPU's idle task is always considered as a
> + member of the group owning the CPU.
>
This is a valuable addition. Thank you very much for adding it.
> "cpus":
> Reading this file shows a bitmask of the logical CPUs owned by
Reinette