compute_par...tive_cpumask(9)

๐Ÿ“ฆ version 7.3.1, in nixpkgs unstable

๐Ÿ’… compute_partition_effective_cpumask(9) โ€” from the Kernel API Manual, bestie ๐ŸŽ€

okay so picture this: it's a (9) manpage, it lives in the Kernel API Manual, and its whole personality is "figure out a partition's effective CPU mask." her name got a little chopped in the header (compute_par...tive_cpumask(9)) like she's texting from a bad signal, but she's iconic, we move. โœจ


๐ŸŒธ NAME ๐ŸŒธ

compute_partition_effective_cpumask โ€” literally just computes effective_cpus for a partition. that's the whole gig, no cap ๐Ÿ’–


๐Ÿฆ‹ SYNOPSIS ๐Ÿฆ‹

void compute_partition_effective_cpumask (struct cpuset *cs , struct cpumask *new_ecpus );

like yes, that's the signature, copy it exactly, do NOT freestyle it ๐Ÿ™ˆ


๐ŸŽ€ ARGUMENTS ๐ŸŽ€

  • cs โ€” the partition root cpuset. the main character of this whole operation ๐Ÿ‘‘
  • new_ecpus โ€” the effective_cpus that was previously computed, and which we're about to update. so she's not new-new, she's getting a glow-up โœจ

๐Ÿ’œ DESCRIPTION ๐Ÿ’œ

So here's the vibe: this function computes the effective_cpus of a partition root by scanning effective_xcpus of child partition roots and excluding their effective_xcpus. that's it, that's the math ๐Ÿงฎ

She's got a side effect though โ€” and it's a real one, so listen up: this has the side effect of invalidating valid child partition roots, if necessary. not me casually invalidating children ๐Ÿ˜ญ but it's fine, it's on purpose.

Why is it fine? Because she's called from either cpuset_hotplug_update_tasks or update_cpumasks_hier, where parent and children are modified successively. so we don't need to call update_parent_effective_cpumask, and the child's effective_cpus will be updated in later iterations anyway. slay, deferred work, queen of not doing things twice ๐Ÿ’…

๐Ÿซถ little heads-up, bestie: rcu_read_lock is assumed to be held. assumed. like, she's trusting you. don't betray her. hold the lock fr fr.

๐ŸŒˆ SEE ALSO ๐ŸŒˆ

Kernel file ./kernel/cgroup/cpuset.c, plus this absolutely stacked friend group ๐Ÿ’–:


and that's the page!! ๐Ÿ“ she ships from ./kernel/cgroup, dated October 2026, and she's filed under compute_par...tive_cpumask(9). mwah, go hold that rcu lock, ily ๐Ÿงš๐Ÿ’œ

๐Ÿ“ฆ where this page comes from