Once upon a time, an operating system scheduler was TheOne_ entity in charge of deciding what "activity" would run on a physical processor. Furthermore, such "activity" would pretty much all the time be an application (or system) program. Well, guess what: these days, things are more complicated! Applications and physical processors have moved away from each other, as one or more layers have been put in between them. In fact, in a typical virtualization/cloud scenario, we have a hypervisor, providing the abstraction of virtual processors, and it is onto them that applications run. And here we are: running an application inside a virtual machine requires a virtual processor to be scheduled on a physical processor --at the host level-- and the application itself to be scheduler on the virtual processor --at the guest level. So, two schedulers (at least!).

But how do these two schedulers interact right now? How should they interact ideally? Should they be closely related, completely independent, or something in the middle? Are they better be based on the same algorithm? Or do different layers have different enough needs to require highly specific solutions?

This talk will go through the above (and more) questions, trying to outline pros and cons of a few approaches. That will happen both in a "theoretical" and practical sense. The latter meaning that we will be looking at some real scheduling traces (at both host and guest level), and at numbers from different benchmarks. The main focus, especially of the 'case study' part, will be on the Xen's scheduler(s) (i.e., on the interactions between Xen's and Linux's schedulers) but we will have a look at a few KVM data points as well.

One Scheduler to rule them all. One Scheduler to find them, One Scheduler to bring them all and...