Re: [PATCH RFC v1 1/4] rt: Add rt scheduler to hypervisor

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

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

On ven, 2014-07-11 at 15:37 +0100, Andrew Cooper wrote:
> On 11/07/14 05:49, Meng Xu wrote:

> > +/*
> > + * Virtual CPU
> > + */
> > +struct rt_vcpu {
> > +    struct list_head runq_elem; /* On the runqueue list */
> > +    struct list_head sdom_elem; /* On the domain VCPU list */
> > +
> > +    /* Up-pointers */
> > +    struct rt_dom *sdom;
> > +    struct vcpu *vcpu;
> > +
> > +    /* VCPU parameters, in milliseconds */
> > +    s_time_t period;
> > +    s_time_t budget;
> > +
> > +    /* VCPU current infomation */
> > +    long cur_budget;             /* current budget in microseconds */
> 
> Can budget be negative ?
> 
It depends on how you implement the core of the algorithm. Current SEDF
uses a cputime counter, which always increase, and checks whether budget
is being overcome with something lien (cputime >= budget).

Meng's implementation here does the opposite, initializes cur_budget
with budget, and subtract actual execution time from there, until it
reaches zero or, in case of overrun, below zero.

So, yes, if we stick with this version of things (which is perfectly
fine), I think cur_budget should be allowed to go negative.

However, I'd use s_time_t for it it, rather than long.

> >  #define XEN_SCHEDULER_CREDIT   5
> >  #define XEN_SCHEDULER_CREDIT2  6
> >  #define XEN_SCHEDULER_ARINC653 7
> > +#define XEN_SCHEDULER_RT       8
> > +
> >  /* Set or get info? */
> >  #define XEN_DOMCTL_SCHEDOP_putinfo 0
> >  #define XEN_DOMCTL_SCHEDOP_getinfo 1
> > @@ -367,6 +383,9 @@ struct xen_domctl_scheduler_op {
> >          struct xen_domctl_sched_credit2 {
> >              uint16_t weight;
> >          } credit2;
> > +        struct xen_domctl_sched_rt{
> > +            XEN_GUEST_HANDLE_64(xen_domctl_sched_rt_params_t) schedule;
> > +        } rt;
> 
> Thinking more generally, is rt an appropriate name here?  It seems a
> little generic, as there are several classes of realtime schedulers
> employing different semantics and parameters.
> 
That's true. The challenge here is finding a name which is
representative enough of the specific characteristics of the scheduler,
without it being known only in real-time research rooms! :-O

I'd stick with sched_rt.c for the filename, as it's an implementation of
EDF, after all, on top of which (read: in the same file) you can
potentially implement a bunch of different scheduling algorithms and
policies.

This particular one is called "Deferrable Server" (DS). Since it's on
top of EDF, which is a dynamic priority algorithm, it is sometimes
called "Dynamic Deferrable Server" (DDS). It's also part of a class of
algorithms known as "Resource Reservation" algorithms, which is how
(well, one of the ways with which) the RT community refers to algos with
a budgetting scheme inside it.

So, ideas? RTDS (as per Real-Time Deferrable-Server)? RRESDS (Resource
Reservation Deferrable Server)? Just DS (Deferrable Server)?

I'm not sure I like much any of these...

What was it that you had in mind when you said "there are several
classes of realtime schedulers employing different semantics and
parameters" ?

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: 181 bytes --]

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

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