Implement CPU Affinity: Pin Processes to Specific Cores

Pinning to Cores

CPU affinity restricts which hardware threads may run a process. The scheduler still picks order, but the allowed set shrinks. Database engines pin worker threads to reduce cache migration; container runtimes expose affinity through cgroup cpuset.

How Affinity Is Expressed

Linux exposes masks and syscalls:

• cpu_set_t: bit mask of permitted CPUs
• sched_setaffinity(): apply mask to a task
• /proc/self/status: Cpus_allowed_list shows effective mask

For example, pinning PID 9000 to CPUs {2,3} means the run queue for that task never dispatches on CPU 0 even if it is idle.

Why This Matters in Production

This is the exact mechanism behind Linux's taskset and sched_setaffinity(2), which production systems use to pin latency-sensitive workloads like Redis or DPDK packet processors away from cores handling interrupts, avoiding cache-line bouncing across NUMA nodes. Getting affinity-aware load balancing wrong is a real operational trap: pinning too many processes to one core creates the exact imbalance this task asks you to demonstrate.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will maintain an affinity mask per PCB and filter runnable tasks during dispatch. The exercise requires measuring migration counts before and after pinning to show fewer cross-core context switches.