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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2016-04-26 at 14:38 -0400, Meng Xu wrote:
> > So, yes, the scheduler is now feature complete (with the per-vcpu
> > parameters) and adheres to a much more sensible and scalable design
> > (event driven). Yet, these features have been merged very recently,
> > therefore, when you say "tested", I'm not so sure I agree. In fact,
> > we
> > do test it on OSSTest, but only in a couple of tests. The
> > combination
> > of these two things make me think that we should allow for at least
> > another development cycle, before considering switching.
> I see. So should we mark it as Completed for Xen 4.7? or should we
> wait until Xen 4.8 to mark it as Completed if nothing bad happens to
> the scheduler?
> 
We should define the criteria. :-)

In any case, not earlier than 4.8, IMO.

> > And even in that case, I wonder how we should handle such a
> > situation... I was thinking of adding a work-conserving mode, what
> > do
> > you think?
> Hmm, I can get why work-conserving mode is necessary and useful. I'm
> thinking about the tradeoff  between the scheduler's complexity and
> the benefit brought by introducing complexity.
> 
> The work-conserving mode is useful. However, there are other real
> time
> features in terms of the scheduler that may be also useful. For
> example, I heard from some company that they want to run RT VM with
> non-RT VM, which is supported in RT-Xen 2.1 version, but not
> supported
> in RTDS.
> 
I remember that, but I'm not sure what "running a non-RT VM" inside
RTDS would mean. According to what algorithm these non real-time VMs
would be scheduled?

Since you mentioned complexity, adding a work conserving mode should be
easy enough, and if you allow a VM to be in work conserving mode, and
have a very small (or even zero) budget, here you are a non real-time
VM.

> There are other RT-related issues we may need to solve to make it
> more
> suitable for real-time or embedded field, such as protocols to handle
> the shared resource.
> 
> Since the scheduler aims for the embedded and real-time applications,
> those RT-related features seems to me more important than the
> work-conserving feature.
> 
> What do you think?
> 
There always will be new/other features... But that's not the point.

What we need, here, is agree on what is the _minimum_ set of them that
allows us to call the scheduler complete and usable. I think we're
pretty close, with this work conserving mode I'm talking about the only
candidate I can think of.

> > 
> > You may have something similar in RT-Xen already but, even
> > if you don't, there are a number of ways for achieving that without
> > disrupting the real-time guarantees.
> Actually, in RT-Xen, we don't have the work-conserving version yet.
>
Yeah, sorry, I probably was confusing it with the "RT / non-RT" flag.

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