Credit2 Scheduler

This page's purpose is to ease collaboration and coordination when doing Credit2 development. It is also meant as a catch-all for everything relating to Credit2 itself.

Status Update

• 2010 24 December: Simple load balancer checked into xen-unstable; credit2 can now handle multiple sockets.
• 2010 December: Credit2 integrated into the OSSTest automated test suite
• 2010 14 April: Credit2 checked into xen-unstable
• Prototype credit2 scheduler designed for latency-sensitive workloads and very large systems included in Xen 4.1

Contributing

Thoughts, suggestions, questions and patches via email to xen-devel. See the list info page for subscription information and the archives.

If asking questions, please refer to Asking Developer Questions. If sending patches, please see Submitting Xen Patches.

Current State

• Reliability
  • Integrated into the regular test suite; seems to be very stable
• Fairness algorithm
  • "Weight" implemented; "Cap" and "Reservation" not implemented.
  • More fair to latency-sensitive VMs than credit2.
  • Not optimized well; probably more computational overhead than credit1
  • Not tested extensively with other combinations of workloads
• Load-balancing algorithm
  • Prototype working, tested on 2-socket box
  • Not optimized well; probably more computational overhead than credit1
  • Not tested extensively with many combinations of workloads
  • No accounting for hyperthreading

To-do

• Development: CPU topology
  • Load balancing algorithm: There's a fairly simple load-balancing algorithm in place, but it could use some work.
  • Hyperthreading: Need to try to avoid sharing threads if possible, and to "discount" sharing of threads
• Development: Credit algorithm
  • Mixed work problem: The current patch will work well if a VM is only doing audio. But what if someone is listening to iTunes and there's a flash ad in the background burning 100% of the CPU? Can we allow the audio to play well while still giving the VM only its fair share?
  • Cap and Reservation: With the current algorithm, how do we implement the "cap" and "reservation" features?
• Development: Honing
  • Credit math optimization: The current patch was made to be correct, not necessarily the most efficient. Every credit update involves a division, which may be slow. Some profiling and optimization would be useful here. Probably best to wait on this until the cap and reservation system is working, because the algorithm may change somewhat.
• Testing
  • Automated audio / video measurement: My current method of measuring audio quality is to play some music and count the number of "skips" I hear over five minutes. It would be great if this could be done programmatically somehow.
  • More workloads, more configurations: Test your favorite workload, and see if there are any regressions, improvements, and so on. Remember that a scheduler's job is only hard when there's more work to do than there is CPU to do it, so make sure you're focusing on multiple competing workloads.
  • Test framework design: I would like to have a standardized set of regression tests that can be run as we develop the scheduler, to see (a) when we've gotten where we want to be, and (b) so in the future, if anyone proposes a change, we can test the change for any regressions in other workloads.

References

• IN PERFECT XEN, A PERFORMANCE STUDY OF THE EMERGING XEN SCHEDULER (Dec 2013)
• XenSummit Asia 2009: a brief summary of the design target, goals, interface, credit design, and load balancing design. (text slides)