Re: [PATCH v2 1/4] xen: credit2: implement utilization cap

[George Dunlap <george.dunlap@citrix.com>]

On 08/18/2017 04:50 PM, Dario Faggioli wrote:
> This commit implements the Xen part of the cap mechanism for
> Credit2.
> 
> A cap is how much, in terms of % of physical CPU time, a domain
> can execute at most.
> 
> For instance, a domain that must not use more than 1/4 of
> one physical CPU, must have a cap of 25%; one that must not
> use more than 1+1/2 of physical CPU time, must be given a cap
> of 150%.
> 
> Caps are per domain, so it is all a domain's vCPUs, cumulatively,
> that will be forced to execute no more than the decided amount.
> 
> This is implemented by giving each domain a 'budget', and
> using a (per-domain again) periodic timer. Values of budget
> and 'period' are chosen so that budget/period is equal to the
> cap itself.
> 
> Budget is burned by the domain's vCPUs, in a similar way to
> how credits are.
> 
> When a domain runs out of budget, its vCPUs can't run any
> longer. They can gain, when the budget is replenishment by
> the timer, which event happens once every period.
> 
> Blocking the vCPUs because of lack of budget happens by
> means of a new (_VPF_parked) pause flag, so that, e.g.,
> vcpu_runnable() still works. This is similar to what is
> done in sched_rtds.c, as opposed to what happens in
> sched_credit.c, where vcpu_pause() and vcpu_unpause()
> (which means, among other things, more overhead).
> 
> Note that, while adding new fields to csched2_vcpu and
> csched2_dom, currently existing members are being moved
> around, to achieve best placement inside cache lines.
> 
> Note also that xenalyze and tools/xentrace/format are being
> updated too.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Looks good, with one minor nit...


> +        /*
> +         * NB: we give the whole remaining budget a domain has, to the first
> +         * vCPU that comes here and asks for it. This means that, in a domain
> +         * with a cap, only 1 vCPU is able to run, at any given time.
> +         * /THIS IS GOING TO CHANGE/ in subsequent patches, toward something
> +         * that allows much better fairness and parallelism. Proceeding in
> +         * two steps, is for making things easy to understand, when looking
> +         * at the signle commits.

*single

But I can fix that up on check-in.

Reviewed-by: George Dunlap <george.dunlap@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel