Re: [PATCH v3 1/4] xen: add real time scheduler rtds

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Sep 18, 2014 at 05:08:45PM +0100, George Dunlap wrote:
> On 09/14/2014 10:37 PM, Meng Xu wrote:
> >This scheduler follows the Preemptive Global Earliest Deadline First
> >(EDF) theory in real-time field.
> >At any scheduling point, the VCPU with earlier deadline has higher
> >priority. The scheduler always picks the highest priority VCPU to run on a
> >feasible PCPU.
> >A PCPU is feasible if the VCPU can run on this PCPU and (the PCPU is
> >idle or has a lower-priority VCPU running on it.)
> >
> >Each VCPU has a dedicated period and budget.
> >The deadline of a VCPU is at the end of each period;
> >A VCPU has its budget replenished at the beginning of each period;
> >While scheduled, a VCPU burns its budget.
> >The VCPU needs to finish its budget before its deadline in each period;
> >The VCPU discards its unused budget at the end of each period.
> >If a VCPU runs out of budget in a period, it has to wait until next period.
> >
> >Each VCPU is implemented as a deferable server.
> >When a VCPU has a task running on it, its budget is continuously burned;
> >When a VCPU has no task but with budget left, its budget is preserved.
> >
> >Queue scheme:
> >A global runqueue and a global depletedq for each CPU pool.
> >The runqueue holds all runnable VCPUs with budget and sorted by deadline;
> >The depletedq holds all VCPUs without budget and unsorted.
> >
> >Note: cpumask and cpupool is supported.
> >
> >This is an experimental scheduler.
> >
> >Signed-off-by: Meng Xu <mengxu@cis.upenn.edu>
> >Signed-off-by: Sisu Xi <xisisu@gmail.com>
> 
> Getting there, but unfortunately I've got a number more comments.
> 
> Konrad, I think this is very close to being ready -- when is the deadline
> again, and how hard is it?  Would it be better to check it in before the

Sep 23.
> deadline, and then address the things I'm bringing up here?  Or would it be
> better to wait until all the issues are sorted and then check it in (even if
> it's after the deadline)?

We can check it in after the deadline - and have those issues resolved.

I am basing this on the assumption that:
 - The risks of regressions to the rest of schedulers is nill (as this is all
   new codepaths (as this is all
 - The risks of regressions to the rest of the code-base is nill (as this is all
   new).
 - The resolution of the 'couple of things' are not going to lead to more
   'couple of things' and lead to re-design.
 - I am OK with this having bugs (ones that haven't been discovered, or just
   now discovered) - as long as we aim to have them fixed.

The common code that is touched does not look scary to me. And both of the
scheduler maintainers -  you and Dariof are OK with the design and the patchset
(minus the 'couple of things').

Are we aim to have this be experimental for Xen 4.5 or do we want this
to be on the 'stable' ?