This is nifty, but not really congruent with my understanding of the "noisy neighbor" phenomenon. This work seems to reveal when there are more runnable threads than CPUs, leading to tasks waiting to run. The way I use "noisy neighbor" is that it is a concurrent task that trashes some microarchitectural resource, forcing the victim process to use more CPU time. For example, a process on another CPU core in the same cache domain that trashes all of the shared cache lines, or fills up all the load/store slots, or that uses more thermal power causing a global clock speed slowdown.
I thought so too - it seems like this is more about "who is being preempted by who" (although maybe noisy neighbor in the sense of "hogging up CPU time" does often imply "polluting hardware resources" to some degree, especially considering these machines probably have SMT)
Yep in Netflix case they pack bare-metal instances with a very large amount of containers and oversubscribe them (similar to what Borg reports: hundreds of containers per VM is common), so there are always more runnable threads than CPUs and your runqueues fill up.
I'm curious as to the capacity of the bare metal hosts you operate such that you can oversubscribe CPU without exhausting memory first or forcing processes to swap (which leads to significantly worse latency than typical scheduling delays). My experience is that most machines end up being memory bound because modern software—especially Java workloads, which I know Netflix runs a lot of—can be profligate memory consumers.
Workloads tend to average out if you pack dozens or hundreds into one host. Some need more CPU and some need more memory, but some average ratio emerges ... I like 4GB/core.
