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.
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
Credit2 is still marked as experimental software. Development is ongoing in order to make it suitable for production usage. Broadly speaking this is the current status of Credit2:
- stable and reliable; it is part of Xen upstream and of the OSSTest automated test suite since ages
- benchmarking showed improved fairness, with respect to Credit1, especially in latency sensitive workloads
- lacking extensive testing with many and diverse combinations of workloads
- lacking some optimization; both the crediting algorithm and the load balancing logic are, computationally, rather expensive (more than Credit1)
- CPU Topology:
- Hyperthreading: avoid sharing threads if possible, and to "discount" sharing of threads.
- 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
- Load balancing algorithm: There's a fairly simple load-balancing algorithm in place, but it could use some work.
- 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.
- 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.
- 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)