The Linux Scheduler: a Decade of Wasted Cores. As a central part of resource management, the OS thread
scheduler must maintain the following, simple, invariant:
make sure that ready threads are scheduled on available
cores. As simple as it may seem, we found that this invariant
is often broken in Linux. pdf 
These bugs have different root causes, but a common symptom. The scheduler unintentionally and for a long time leaves cores idle while there are runnable threads waiting in runqueues.
Detecting these bugs is difficult. They do not cause the system to crash or hang, but eat away at performance, often in ways that are difficult to notice with standard performance monitoring tools.
With so many rules about when the load balancing does or does not occur, it becomes difficult to reason about how long an idle core would remain idle if there is work to do and how long a task might stay in a runqueue waiting for its turn to run when there are idle cores in the system.
If every good scheduling idea is slapped as an add-on to a single monolithic scheduler, we risk more complexity and more bugs, as we saw from the case studies in this paper. What we need is to rethink the architecture of the scheduler, since it can no longer remain a small, compact and largely isolated part of the kernel.
.
I remember when UNIX Version 5 showed up at Purdue in the early 70's. My friend Jim Bessemer administered an 11/70 and started hacking the scheduler. There was some condition he didn't understand so he putchar(bell) whenever it occurred which wasn't often. Eventually graduate students working in the lab asked why the bell went off two or three times a night.