Re: Should we mark RTDS as supported feature from experimental feature?

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

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

On Tue, 2016-04-26 at 16:00 -0400, Meng Xu wrote:
> > 
> > > 
> > > The feature document template has been put together:
> > > http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg01
> > > 929.html
> > > 
> > > And there are feature documents in tree already.
> > > 
> > > Actually, writing one for RTDS would be a rather interesting and
> > > useful
> > > thing to do, IMO! :-)
> > I think it would be helpful to try to spell out what we think are
> > the
> > criteria for marking RTDS non-experimental.  Reading your e-mail,
> > Dario,
> > I might infer the following criteria:
> > 
> > 1. New event-driven code spends most of a full release cycle in the
> > tree
> > being tested
> > 2. Better tests in osstest (which ones?)
> > 3. A feature doc
> I agree with the above three items.
> 
Great!

> > 4. A work-conserving mode
> I think we need to consider the item 4 carefully. Work-conserving
> mode
> is not a must for real-time schedulers and it is not the main
> purpose/goal of the RTDS scheduler.
> 
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. :-)

> > Regarding #2, did you have specific tests in mind?
> I've been thinking about how to confirm the correctness of (RTDS)
> schedulers. It is actually quite challenging to prove the scheduler
> is
> correct.
> 
> I'm thinking what the goal of the tests is? It will determine how the
> scheduler should be tested, IMHO.
> There are three possible goals in increasing difficulty:
> (1) Make sure the scheduler won't crash the system, or
> (2) make sure the performance of the scheduler is correct, or
> (3) prove the scheduler is correct?
> 
> Which one are we talking about here? (maybe item 1?)
> 
Definitely 1, with all the security related implications that applies
to it (e.g., if a guest running within RTDS could crash or DoS the
entire host, that would be a security issue).

Good performance is important, but we'd need to define what 'good
performance' means. And since this is the only (online) real-time
scheduler we have, maybe that is not really necessary for now (e.g.,
'good performance', as compared to what?).

Assessing correctness of the actual schedule is interesting, but beyond
the scope of what I'd call 'supported status'. :-)

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