Credit2 Scheduler

From Xen
Revision as of 15:46, 13 January 2015 by Dariof (talk | contribs) (Added an Introduction)

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.

Introduction

Credit2 is a general purpose scheduler for Xen, designed with the following goal in mind:

  • fairness: fairness is the ability of the scheduler to give each VM its fair share of physical CPU capacity. Such fair share should depend on the VM's scheduling parameters, such as weight, cap, and reservation.
  • responsiveness: responsiveness should be intended here as the capability of the scheduler to work well with latency-sensitive workloads.

These design goals have been derived from the more general objective to create a scheduler which can work well in several use cases, with particular attention to:

  • server consolidation
  • virtual desktop server solutions
  • client virtualization

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.

Status

Some milestones:

  • 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

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