Re: [Design RFC] Towards work-conserving RTDS scheduler

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

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

On Tue, 2016-08-09 at 09:57 -0400, Meng Xu wrote:
> On Mon, Aug 8, 2016 at 5:38 AM, Dario Faggioli
> <dario.faggioli@citrix.com> wrote:
> > 
> > I'm just thinking out loud and
> > wondering:
> >  - could it be useful to have a scheduling analysis in place for
> > the
> >    scheduler in work conserving mode (one, of course, that takes
> > into
> >    account and give guarantees on the otherwise idle bandwidth... I
> >    know that the existing one holds! :-P) ?
> >  - if yes, do you already have one --or do you think it will be
> >    possible to develop one-- for your priority-index based model?
> I think I could potentially develop one such analysis.
> 
Great. Let me know if you need any help writing the paper! :-P

> > Actually, it's quite likely that you either have already noticed
> > this
> > and done the analysis, or that someone else in literature has done
> > something similar --maybe with other schedulers-- before.
> Yes, I noticed this but I don't have analysis yet. ;-) I will do some
> math formulas to model this situation.
> I'm thinking the desired design will be
> 1) Work-conserving scheduler;
> 2) A *tight* schedulability analysis. If we cannot get tight
> analysis,
> we should reduce the abstraction overhead, i.e., num_cores -
> utilization of all VCPUs. (In order to achieve better analysis, we
> may
> need to change the scheduling policy a bit. I'm not very clear about
> how to do it yet, but I will think about it.)
> 
Err... I'm not sure I got what you exactly mean here, but this is your
field, just go ahead with it without bothering explaining everything to
me. :-)

> > Anyway, the idea itself looks fair enough to me. I'd like to hear,
> > if
> > that's fine with you, how you plan to actually implement it, as
> > there
> > of course are multiple different ways to do it, and there are, IMO,
> > a
> > couple of things that should be kept in mind.
> How about letting me think about the analysis first. If we can have
> both the work-conserving algorithm and the analysis, that will be
> better. If we finally decide not to have the analysis, we can fall
> back to the discussion of the current design?
> 
Sure.

> > Finally, about the work-conserving*ness on-off switch, what added
> > difficulty or increase in code complexity prevents us to, instead
> > of
> > this:
> > 
> > "2) Priority index: It indicates the current  priority level of the
> >     VCPU. When a VCPU’s budget is depleted in the current period,
> > its
> >     priority index will increase by 1 and its budget will be
> >     replenished."
> > 
> > do something like this:
> > 
> > "2) Priority index: It indicates the current  priority level of the
> >     VCPU. When a VCPU's budget is depleted in the current period:
> >      2a) if the VCPU has the work conserving flag set, its priority
> >          index will be increased by 1, and its budget replenished;
> >      2b) if the VCPU has the work conserving flag cleat, it's
> > blocked
> >          until next period."
> > 
> > ?
> Agree. We can have the per-VCPU working-conserving flag.
> 
Glad you see it useful/doable too.

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 #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