Re: [Xen-devel] [PATCH] Make credit2 the default scheduler

[George Dunlap <dunlapg@xxxxxxxxx>]

On Thu, Sep 13, 2018 at 5:39 PM George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
>
> Credit2 was declared "supported" in 4.8, and as of 4.10 had two other
> critical features implemented (soft affinity / NUMA and caps).
>
> Why change the default?
>
> The code is better: more predictable, less jitter, easier to determine
> how modifications will affect overall behavior, easier in the future
> to make load-balancing behavior more subtle (e.g., taking into account
> the cost of powering up extra cores, &c).
>
> Overall performance compared to Credit1 is somewhat of a mixed bag.
> Unfortunately most of what I have are tests using XenServer's internal
> perf testing system, so I can't share the raw data (via links anyway).
>
> Here is a summary of data from an internal e-mail Dario sent in the
> past:
>
> * DVDbench: On underloaded systems, credit2 outperformed credit1 by
> about 4%.  On overloaded systems, credit2 underperformed by about 3%.
>
> * On a range of tests (unixbench, lmbench, &c), credit and credit2
> perform within 5% of each other (up and down).
>
> * Credit2 fairly consistently beats credit for TCP-style workloads.
>
> * Credit2 is sometimes equal to, sometimes 5-15% worse than, credit for
> synthetic CPU workloads (e.g., Dhrystone).
>
> * On LoginVSI, credit2 fairly consistently outperforms credit by about 10%.
>
> Credit2, like credit, has a number of workloads / setups for which
> performance could be improved.  Personally I think networking and
> partially-loaded systems is going to be more representative of what
> Xen is actually used for; so I think credit2 is on the whole the
> better scheduler to use by default.  And in any case, making those
> improvements on credit2 will be easier than on credit.
>
> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>

The fix for the migration issue has passed the push gate; I plan on
re-applying this change again (un-reverting the revert) Monday unless
I hear any objections.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel