4 CPUs, 1 idle: how operating systems schedule multiple cores | OSTEP Ch. 10

Four CPUs, one shared queue, or one queue per CPU? Reading OSTEP Chapter 10 (Multiprocessor Scheduling) page by page: why caches make multicore hard, why a single lock stops scaling, and how a scheduler can leave a CPU sitting idle while work piles up next door. As a kernel engineer, I add the parts the book skips. The on-screen cards cover cache coherence, bus snooping with write-back caches, the List_Pop race, TLBs and work stealing. Operating Systems: Three Easy Pieces (free online): https://pages.cs.wisc.edu/~remzi/OSTEP/ This chapter (PDF): https://pages.cs.wisc.edu/~remzi/OSTE... Chapters 0:00 Recap: the chapter in 70 seconds 1:10 Intro 4:51 10.1 Background: multiprocessor architecture 11:36 10.2 Don't forget synchronization 14:41 10.3 Cache affinity 15:56 10.4 Single-queue scheduling (SQMS) 18:38 10.5 Multi-queue scheduling (MQMS) 24:39 10.6 Linux multiprocessor schedulers 25:45 10.7 Summary 26:18 Up next: the multi.py homework SQMS vs MQMS in one line each SQMS: one shared queue. Simple and balances load, but every CPU fights over one lock and jobs bounce between caches. MQMS: one queue per CPU. Scales and keeps cache affinity, but needs migration (work stealing) to fix load imbalance. Linux has shipped both: O(1) and CFS use per-CPU queues, BFS used a single queue. Since Linux 6.6, EEVDF has replaced CFS. Next up: the multiprocessor homework with multi.py. #operatingsystems #systemsprogramming #ostep #linux #multicore #computerscience