cpuset_update_tasks_cpumask(9)
π cpuset_update_tasks_cpumask(9) β the Kernel API Manual, bestie edition π
okay so real talk, this is a page from the Kernel API Manual, and it's all about cpuset_update_tasks_cpumask. yes that's a mouthful, no i will not be shortening it, it's iconic and it knows it β¨
πΈ NAME πΈ
cpuset_update_tasks_cpumask β update the cpumasks of tasks in the cpuset. that's the whole vibe. one job, does it well, slays π«Ά
β¨ SYNOPSIS β¨
void cpuset_update_tasks_cpumask (struct cpuset *cs , struct cpumask
*new_cpus );
literally that's it. void return, no notes π
π¦ ARGUMENTS π¦
csβ the cpuset in which each task'scpus_allowedmask needs to be changed. it's the main character here, giving "i contain multitudes (of tasks)" energy πnew_cpusβ the temp variable for the neweffective_cpusmask. a little scratchpad, a little sidekick, doing the werk socscan shine π
π DESCRIPTION π
so what actually happens? we iterate through each task of cs, updating its cpus_allowed to the effective cpuset's. and here's the key deets, no cap: this function is called with cpuset_mutex held, which is exactly why cpuset membership stays stable while we're walking the list. the lock is holding it down, fr fr π₯
β οΈ heads up bestie: the stability thing? it's because cpuset_mutex is held. don't go thinking it's stable for free, the lock is doing the heavy lifting π
for top_cpuset, task_cpu_possible_mask is used instead of effective_cpus β and why? to make sure all offline CPUs are also included, because hotplug code won't update cpumasks for tasks in top_cpuset. so like, the offline girlies are still invited to the party π
and because task_cpu_possible_mask can be task dependent in arm64, we have to do cpu masking per task instead of doing it once for all. yeah. one at a time. individually. it's giving "we tried batching and it didn't work out" π
π₯ SEE ALSO π₯
okay this list is LONG, grab a snack π β all of these live in the Kernel file ./kernel/cgroup/cpuset.c:
cpuset_lock(9)cpuset_full_lock(9)partition_is_populated(9)alloc_cpumasks(9)alloc_tmpmasks(9)free_tmpmasks(9)dup_or_alloc_cpuset(9)free_cpuset(9)cpus_excl_conflict(9)compute_effective_cpumask(9)compute_effective_nodemask(9)rm_siblings_excl_cpus(9)update_parent_effective_cpumask(9)compute_partition_effective_cpumask(9)update_sibling_cpumasks(9)validate_partition(9)partition_cpus_change(9)update_cpumask(9)update_exclusive_cpumask(9)cpuset_update_tasks_nodemask(9)update_prstate(9)cpuset_css_alloc(9)cpuset_init(9)cpuset_hotplug_update_tasks(9)cpuset_handle_hotplug(9)cpuset_init_smp(9)cpuset_cpus_allowed_locked(9)cpuset_cpus_allowed(9)cpuset_cpus_allowed_fallback(9)cpuset_mems_allowed(9)cpuset_nodemask_valid_mems_allowed(9)cpuset_nodes_allowed(9)cpuset_spread_node(9)cpuset_mem_spread_node(9)cpuset_mems_allowed_intersects(9)cpuset_print_current_mems_allowed(9)
like i said. long. but every single one of them is a real one, go read them, iykyk π
and that's the page!! π this one comes to you from ./kernel/cgroup, dated October 2026, and it's filed under cpuset_update_tasks_cpumask(9) β mwah, go touch some cpumasks, ily π«Άπβ¨
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms