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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 09/14/2017 05:20 PM, George Dunlap wrote:
> 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@xxxxxxxxxx>
> 
> 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.

Well turns out it gets clobbered in the 3rd patch anyway.  But at least
we a well-spelled commit history. :-)

 -George

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