Re: [Xen-devel] Should we mark RTDS as supported feature from experimental feature?

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2016-04-26 at 21:16 -0400, Meng Xu wrote:
> > It's indeed not a must for real-time schedulers. In fact, it's only
> > important if one wants the system to be overall usable, when using
> > a
> > real-time scheduler. :-P
> > 
> > Also, I may be wrong but it should not be too hard to implement...
> > I.e., a win-win. :-)
> I'm thinking if we want to implement work-conserving policy in RTDS,
> how should we allocate the unused resource to domains. Should this
> allocation be promotional to the budget/period each domain is
> configured with?
> I guess the complexity totally depends on which work-conserving
> algorithm we want to encode into RTDS.
> 
Indeed it does.

Everything works for me, basically. As you say, it would not be a
critical aspect of this scheduler, and the implementation details of
the work conserving mode is not going to be the reason why people
choose it anyway... It's just to avoid that people runs away from it
(and from Xen) screaming! :-)

So, for instance, how do you manage non real-time VMs in RT Xen? You
say you still use EDF, how do you do that? When does one non real-time
VM preempt another non real-time VM? (Ideally, I'd go and check the RT-
Xen code that does this myself, but right now, I can't, sorry.)

We could go for this that you have already, and as soon as a VM
exhausts its budget, we demote it to non real-time, until it receives
the replenishment. Or something like that.

In this case, we basically get two features at the cost of one (support
for non real-time VMs and work conserving mode for real-time VMs). Not
to mention that you basically have the code already, and "only" need to
upstream it! :-DD

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
Description: This is a digitally signed message part

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