multicore scalability
Modern chips have many CPU cores — 4, 16, 64, or more — and scalability is the question of whether adding cores actually makes the work go faster. Ideally, doubling the cores would halve the time. In practice it rarely does. Picture a kitchen: one extra cook helps a lot, but at some point too many cooks crowd the one sink and the one stove, and adding more cooks stops helping or even slows things down. The bottleneck shifts from doing the work to coordinating who can do it.
Inside an operating system, the chief obstacle is shared state guarded by locks. If many cores all need the same lock to update the same data structure (say, a single global ready queue), they line up and wait, and the cores serialize instead of running in parallel — this is lock contention. The remedy is to reduce sharing: use fine-grained locks instead of one big lock, give each core its own per-core data so it rarely needs to talk to others, and use lock-free or read-mostly techniques (such as read-copy-update) so readers do not block. Hardware effects matter too: cache coherence traffic and false sharing (two cores fighting over the same cache line even though they touch different variables) can quietly destroy scaling. The Linux scheduler, for instance, keeps per-core run queues precisely so cores do not contend on one global lock.
The honest law here is Amdahl's law: if even a small fraction of the work must run serially (one lock everyone needs, one shared counter), that serial part caps the speedup no matter how many cores you add. So perfect linear scaling is the exception, not the rule. The art of scalability is removing serialization wherever it hides; the brutal reality is that some always remains.
A server with one global lock around its connection table runs fine on 4 cores but barely faster on 64 — the cores spend their time waiting for that one lock. Splitting the table into per-core shards, each with its own lock, lets the cores work independently, and throughput finally climbs close to linearly with the core count.
One shared lock serializes the cores; per-core data lets them run in parallel.
More cores do not guarantee more speed. By Amdahl's law the serial fraction — any work that must happen one-at-a-time under a shared lock — sets a hard ceiling, so scaling is about removing sharing, not just adding hardware.