]> git.ipfire.org Git - thirdparty/linux.git/commitdiff
fs/resctrl: Document tasks file behaviour for task id 0 and idle tasks
authorBen Horgan <ben.horgan@arm.com>
Wed, 6 May 2026 08:28:55 +0000 (09:28 +0100)
committerBorislav Petkov (AMD) <bp@alien8.de>
Fri, 8 May 2026 10:27:00 +0000 (12:27 +0200)
When 0 is written to the tasks file it is interpreted as the current task in
rdtgroup_move_task(). Each CPU's idle task has task_struct::pid set to 0 and,
on x86, task_struct::closid to RESCTRL_RESERVED_CLOSID and task_struct::rmid
to RESCTRL_RESERVED_RMID.

Equivalently, on MPAM platforms, thread_info::mpam_partid_pmg is encoded with
PARTID and PMG set to 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_list files.

On read of the tasks file, show_rdt_tasks() filters out any 0 PID. Hence, 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>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Babu Moger <babu.moger@amd.com>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Tested-by: Babu Moger <babu.moger@amd.com>
Link: https://lore.kernel.org/20260506082855.3694761-1-ben.horgan@arm.com
Documentation/filesystems/resctrl.rst

index b388e9193896ee2c0f57aa4d7a10712c790d1bad..e4b66af55ffba045c3fd2fe1352a4b5e4341ed74 100644 (file)
@@ -575,6 +575,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.
 
 "cpus":
        Reading this file shows a bitmask of the logical CPUs owned by