On Sat, 2017-08-05 at 17:35 -0400, Meng Xu wrote:
> >
> > > @@ -966,8 +1001,16 @@ burn_budget(const struct scheduler *ops,
> > > struct
> > > rt_vcpu *svc, s_time_t now)
> > >
> > > if ( svc->cur_budget <= 0 )
> > > {
> > > - svc->cur_budget = 0;
> > > - __set_bit(__RTDS_depleted, &svc->flags);
> > > + if ( is_work_conserving(svc) )
> > > + {
> > > + svc->priority_level++;
> > >
> >
> > ASSERT(svc->priority_level <= 1);
>
> I'm sorry I didn't see this suggestion in previous email. I don't
> think this assert makes sense.
>
> A vcpu that has extratime can have priority_level > 1.
> For example, a VCPU (period = 100ms, budget = 10ms) runs alone on a
> core. The VCPU may get its budget replenished for 9 times in a
> period. the vcpu's priority_level may be 9.
>
Ah, ok. Yes, I missed this, while I see this now.But doesn't this mean that, at a certain time t, between both CPUs that are both in 'etratime mode' (i.e., they've run out of budget, but they're running because they have extratime set), the one that has received less replenishments gets priority? Is this wanted or expected? Basically, if I'm not wrong, this means that the actual priority, during the extratime phase, is some combination of deadline and budget (which would make me think to utilization)... is this the case? I don't care much about the actual schedule during the extratime phase, in the sense that it doesn't have to be anything too complicated or super advanced... but I at least would like: - to know how it works, and hence what to expect, - for it to be roughly fair. 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)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
