On Fri, 2017-09-01 at 11:58 -0400, Meng Xu wrote: > Make RTDS scheduler work conserving without breaking the real-time > guarantees. > > VCPU model: > Each real-time VCPU is extended to have an extratime flag > and a priority_level field. > When a VCPU's budget is depleted in the current period, > if it has extratime flag set, > its priority_level will increase by 1 and its budget will be > refilled; > othewrise, the VCPU will be moved to the depletedq. > > Scheduling policy is modified global EDF: > A VCPU v1 has higher priority than another VCPU v2 if > (i) v1 has smaller priority_leve; or > (ii) v1 has the same priority_level but has a smaller deadline > > Queue management: > Run queue holds VCPUs with extratime flag set and VCPUs with > remaining budget. Run queue is sorted in increasing order of VCPUs > priorities. > Depleted queue holds VCPUs which have extratime flag cleared and > depleted budget. > Replenished queue is not modified. > Mmm.. didn't we agree about putting a word of explanation of how the spare bandwidth ends up being distributed (i.e., in a way which is proportional to the utilization)? Or is it there and it's me that am not finding it?
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -245,6 +258,11 @@ static inline struct list_head *rt_replq(const
> struct scheduler *ops)
> return &rt_priv(ops)->replq;
> }
>
> +static inline bool has_extratime(const struct rt_vcpu *svc)
> +{
> + return (svc->flags & RTDS_extratime) ? 1 : 0;
> +}
> +
'true' and 'false'. But I think
return svc->flags & RTDS_extratime
is just fine already, without any need for the ?: operator.
The rest of the patch looks fine to me.
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
