Re: [PATCH RFC v1] xen:rtds: towards work conserving RTDS

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2018 bytes --]

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)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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