Re: [Xen-devel] [PATCH] xen:rtds:fix bug in accounting budget

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Oct 19, 2016 at 11:13:54AM -0400, Meng Xu wrote:
> The bug is introduced in Xen 4.7 when we converted RTDS scheduler
> from quantum-driven model to event-driven model.
> We assumed rt_schedule() is always called for a VCPU
> before the VCPUs budget replenished handler.
> This assumption does not hold, when system is overloaded, or
> when the VCPU budget is almost equal its period.
> 
> Buggy behavior:
> 1) A VCPU may get less budget that assigned in a period.
> 2) A full capacity VCPU, i.e., a VCPU whose period is equal to budget,
>    may not get any budget in some period.
> 
> Bug analysis:
> 1) A VCPU deadline can be fast-forwarded by more than one period.
>    However, the VCPU last_start time was not updated immediately.
>    If rt_schedule() is called after rt_update_deadline(), which happens
>    when VCPU budget is equal to period or when VCPU has deadline miss,
>    burn_budget() will burn the budget that was just replenished,
>    although the replenished budget should be used in the most recent period 
> only.
> 
>    We should update VCPU last_start time to the start of the current period
>    when rt_update_deadline() updates a VCPU period.
> 
> 2) When a full capacity VCPU depletes its budget and is context switching out,
>    but has not updated the cores current running VCPU,
>    the budget replenish timer may be triggerred.
>    The replenish handler failed to re-schedule the full capacity VCPU
>    because it thought the VCPU is running.
> 
>    When a VCPU budget is replenished, we try to tickle a CPU.
>    When we find a core for a VCPU to tickle and the VCPU is context switching 
> out,
>    we will always tickle the core where the VCPU was running,
>    if the VCPU cannot find another core to tickle
> 
> This bug was reported by Dagaen Golomb
> 
> Signed-off-by: Meng Xu

You missed you email address here.

Wei.

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