Re: [Xen-devel] [PATCH v2 08/10] xen: credit2: don't miss accounting while doing a credit reset.

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Thu, Feb 9, 2017 at 1:59 PM, Dario Faggioli
<dario.faggioli@xxxxxxxxxx> wrote:
> A credit reset basically means going through all the
> vCPUs of a runqueue and altering their credits, as a
> consequence of a 'scheduling epoch' having come to an
> end.
>
> Blocked or runnable vCPUs are fine, all the credits
> they've spent running so far have been accounted to
> them when they were scheduled out.
>
> But if a vCPU is running on a pCPU, when a reset event
> occurs (on another pCPU), that does not get properly
> accounted. Let's therefore begin to do so, for better
> accuracy and fairness.
>
> In fact, after this patch, we see this in a trace:
>
>  csched2:schedule cpu 10, rq# 1, busy, not tickled
>  csched2:burn_credits d1v5, credit = 9998353, delta = 202996
>  runstate_continue d1v5 running->running
>  ...
>  csched2:schedule cpu 12, rq# 1, busy, not tickled
>  csched2:burn_credits d1v6, credit = -1327, delta = 9999544
>  csched2:reset_credits d0v13, credit_start = 10500000, credit_end = 10500000, 
> mult = 1
>  csched2:reset_credits d0v14, credit_start = 10500000, credit_end = 10500000, 
> mult = 1
>  csched2:reset_credits d0v7, credit_start = 10500000, credit_end = 10500000, 
> mult = 1
>  csched2:burn_credits d1v5, credit = 201805, delta = 9796548
>  csched2:reset_credits d1v5, credit_start = 201805, credit_end = 10201805, 
> mult = 1
>  csched2:burn_credits d1v6, credit = -1327, delta = 0
>  csched2:reset_credits d1v6, credit_start = -1327, credit_end = 9998673, mult 
> = 1
>
> Which shows how d1v5 actually executed for ~9.796 ms,
> on pCPU 10, when reset_credit() is executed, on pCPU
> 12, because of d1v6's credits going below 0.
>
> Without this patch, this 9.796ms are not accounted
> to anyone. With this patch, d1v5 is charged for that,
> and its credits drop down from 9796548 to 201805.
>
> And this is important, as it means that it will
> begin the new epoch with 10201805 credits, instead
> of 10500000 (which he would have, before this patch).
>
> Basically, we were forgetting one round of accounting
> in epoch x, for the vCPUs that are running at the time
> the epoch ends. And this meant favouring a little bit
> these same vCPUs, in epoch x+1, providing them with
> the chance of execute longer than their fair share.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>

Hmm, not sure how I missed that -- I feel like I was calling
"burn_credits()" for other vcpus all the time.  Must have missed one.

Anyway:

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

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