unbound_wq_update_pwq(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

okay bestie, welcome to unbound_wq_update_pwq(9) from the Kernel API Manual β€” this is the page about updating a pwq slot for CPU hot[un]plug, and it's giving very β€œkernel workqueue backstage pass” energy. πŸ’…βœ¨

πŸŽ€ NAME πŸŽ€

unbound_wq_update_pwq β€” update a pwq slot for CPU hot[un]plug


✨ SYNOPSIS ✨

void unbound_wq_update_pwq (struct workqueue_struct *wq , int cpu );

πŸ’– ARGUMENTS πŸ’–

  • wq β€” the target workqueue. like, the queue we're doing this for, periodt.
  • cpu β€” the CPU to update the pwq slot for. this one is the specific CPU slot getting the attention.

🌸 DESCRIPTION 🌸

okay so, this function is to be called from CPU_DOWN_PREPARE, CPU_ONLINE, and CPU_DOWN_FAILED. the cpu you pass is in the same pod of the CPU being hot[un]plugged. no cap.

if pod affinity can't be adjusted due to memory allocation failure, it falls back to wq->dfl_pwq β€” which may not be optimal but is always correct. so yeah, not the prettiest fallback, but it is correct. πŸ’…

⚠️ caveat time, bestie: note that when the last allowed CPU of a pod goes offline for a workqueue with a cpumask spanning multiple pods, the workers which were already executing the work items for the workqueue will lose their CPU affinity and may execute on any CPU. this is similar to how per-cpu workqueues behave on CPU_DOWN.

if a workqueue user wants strict affinity, it's the user's responsibility to flush the work item from CPU_DOWN_PREPARE. that's the rule, fr fr.

πŸ”₯ SEE ALSO πŸ”₯

the kernel file ./kernel/workqueue.c is in the chat, and the whole extended fam is right here:


bye bestie 🫢 this page came from the ./kernel source, dated October 2026, and it's still unbound_wq_update_pwq(9) at heart. slay. πŸ’œ

πŸ“¦ where this page comes from