[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC v1] xen:rtds: towards work conserving RTDS
Hey, Meng! It's really cool to see progress on this... There was quite a bit of interest in scheduling in general at the Summit in Budapest, and one important thing for making sure RTDS will be really useful, is for it to have a work conserving mode! :-) On Tue, 2017-08-01 at 14:13 -0400, Meng Xu wrote: > Make RTDS scheduler work conserving to utilize the idle resource, > without breaking the real-time guarantees. Just kill the "to utilize the idle resource". We can expect that people that are interested in this commit, also know what 'work conserving' means. :-) > VCPU model: > Each real-time VCPU is extended to have a work conserving flag > and a priority_level field. > When a VCPU's budget is depleted in the current period, > if it has work conserving flag set, > its priority_level will increase by 1 and its budget will be > refilled; > othewrise, the VCPU will be moved to the depletedq. > Mmm... Ok. But is the budget burned, while the vCPU executes at priority_level 1? If yes, doesn't this mean we risk having less budget when we get back to priority_lvevel 0? Oh, wait, maybe it's the case that, when we get back to priority_level 0, we also get another replenishment, is that the case? If yes, I actually think it's fine... > diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c > index 39f6bee..740a712 100644 > --- a/xen/common/sched_rt.c > +++ b/xen/common/sched_rt.c > @@ -191,6 +195,7 @@ struct rt_vcpu { > /* VCPU parameters, in nanoseconds */ > s_time_t period; > s_time_t budget; > + bool_t is_work_conserving; /* is vcpu work conserving */ > > /* VCPU current infomation in nanosecond */ > s_time_t cur_budget; /* current budget */ > @@ -201,6 +206,8 @@ struct rt_vcpu { > struct rt_dom *sdom; > struct vcpu *vcpu; > > + unsigned priority_level; > + > unsigned flags; /* mark __RTDS_scheduled, etc.. */ > So, since we've got a 'flags' field already, can the flag be one of its bit, instead of adding a new bool in the struct: /* * RTDS_work_conserving: Can the vcpu run in the time that is * not part of any real-time reservation, and would therefore * be otherwise left idle? */ __RTDS_work_conserving 4 #define RTDS_work_conserving (1<<__RTDS_work_conserving) > @@ -245,6 +252,11 @@ static inline struct list_head *rt_replq(const > struct scheduler *ops) > return &rt_priv(ops)->replq; > } > > +static inline bool_t is_work_conserving(const struct rt_vcpu *svc) > +{ > Use bool. > @@ -273,6 +285,20 @@ vcpu_on_replq(const struct rt_vcpu *svc) > return !list_empty(&svc->replq_elem); > } > > +/* If v1 priority >= v2 priority, return value > 0 > + * Otherwise, return value < 0 > + */ > Comment style. Apart from that, do you want this to return >0 if v1 should have priority over v2, and <0 if vice-versa, right? If yes... > +static int > +compare_vcpu_priority(const struct rt_vcpu *v1, const struct rt_vcpu > *v2) > +{ > + if ( v1->priority_level < v2->priority_level || > + ( v1->priority_level == v2->priority_level && > + v1->cur_deadline <= v2->cur_deadline ) ) > + return 1; > + else > + return -1; > int prio = v2->priority_level - v1->priority_level; if ( prio == 0 ) return v2->cur_deadline - v1->cur_deadline; return prio; Return type has to become s_time_t, and there's a chance that it'll return 0, if they are at the same level, and have the same absolute deadline. But I think you can deal with this in the caller. > @@ -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); > + svc->cur_budget = svc->budget; > + } > + else > + { > + svc->cur_budget = 0; > + __set_bit(__RTDS_depleted, &svc->flags); > + } > } > The rest looks good to me. 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) Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |