Re: [Xen-devel] [PATCH v3 1/4] xen: add real time scheduler rtds

[Meng Xu <xumengpanda@xxxxxxxxx>]

2014-09-22 13:11 GMT-04:00 Dario Faggioli <dario.faggioli@xxxxxxxxxx>:
> On ven, 2014-09-19 at 09:11 -0400, Meng Xu wrote:
>> 2014-09-18 14:08 GMT-04:00 Dario Faggioli <dario.faggioli@xxxxxxxxxx>:
>
>> > Actually, what you're saying about the budget, points at another lack of
>> > the current implementation, i.e., payback for budget overrun (also
>> > mentioned in the same email, I think). That basically means, in the case
>> > you're describing, recognizing that the vcpu in question overran, by
>> > allowing its budget to go negative, and making it pay a price for the
>> > budget to become positive again, in terms on how far its deadline will
>> > be set (this can be implemented quite easily, by slightly changing the
>> > while loop we were discussing above).
>>
>> Hmm, I think we have other ways to pay a price for the overrun budget.
>> For example, we can reduce the budget from its next period to pay for
>> the overrun budget in the current period if it overruns. When we add
>> timers and avoid such MILLISECS(1) scheduling quantum, the overrun
>> budget should not be too much, IMO. But anyway, this is something in
>> the future to solve because it needs to incorporate the extra timers
>> we will add in the future.
>>
> Just FTR, we're talking about the same thing. In fact, I of course meant
> that overrun must be payed in terms of less than full budget in the
> following period. The point is, what it the overuun excedes the budget?
> That's when the "pushing the deadline ahead" comes into play.
>
> Say we have a 40ms budget vcpu that it (somehow) manages tor run for
> 90ms, going down to -50ms.If you push the deadline one period ahead,
> and gives it a recharge of 40ms (i.e., it's full budget), that will
> leave it with -10ms. What I was saying was, in this case, we give it
> another 40ms recharge, but at the price of having its deadline one more
> period ahead.

I see the point and agree with you, although it seems unlikely to have
such a vcpu to overrun 50ms while its budget is 40ms. But anyway, when
this situation happens, I agree with you about the solution.

>
> Anyway, that's for future development, as we agreed.

Sure. When we arrive there I will propose these options and then
settle down one solution to implement.

Thanks,

Meng

>
> Regards,
> Dario
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>



-- 


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

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