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

[George Dunlap <george.dunlap@citrix.com>]

On 26/04/16 08:56, Dario Faggioli wrote:
> On Mon, 2016-04-25 at 21:44 -0400, Meng Xu wrote:
>> Hi Dario and all,
>>
> Hi,
> 
>> When RTDS scheduler is initialized, it will print out that the
>> scheduler is an experimental feature with the following lines:
>>
>>     printk("Initializing RTDS scheduler\n"
>>
>>            "WARNING: This is experimental software in development.\n"
>>
>>            "Use at your own risk.\n");
>>
>> On RTDS' wiki [1], it says the RTDS scheduler is experimental
>> feature.
>>
> Yes.
> 
>> However, inside MAINTAINERS file, the status of RTDS scheduler is
>> marked as Supported (refer to commit point 28041371 by Dario Faggioli
>> on 2015-06-25).
>>
> There's indeed a discrepancy between the way one can read that bit of
> MAINTAINERS, and what is generally considered Supported (e.g., subject
> to security support, etc).
> 
> This is true in general, not only for RTDS (more about this below).
> 
>> In my opinion, the RTDS scheduler's functionality is finished and
>> tested. So should I send a patch to change the message printed out
>> when the scheduler is initialized?
>>
> 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.
> 
> And speaking of OSSTest, there have benn occasional failures, on ARM,
> which I haven't yet found the time to properly analyze. It may be just
> something related to the fact that the specific board was very slow,
> but I'm not sure yet.
> 
> 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? 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.
> 
> What do you think?
> 
>> If I understand correctly, the status in MAINTAINERS file should have
>> the highest priority and information from other sources should keep
>> updated with what the MAINTAINERS file says?
>>
>> Please correct me if I'm wrong.
>>
> This has been discussed before. Have a look at this thread/messages.
> 
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg00972.html
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01775.html
> 
> And at this:
> http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01992.html
> 
> The feature document template has been put together:
> http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg01929.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
4. A work-conserving mode

Is that about right?

#3 definitely sounds like a good idea.  #1 is probably reasonable.

I don't think #4 should be a blocker; we have plenty of work-conserving
schedulers. :-)

Regarding #2, did you have specific tests in mind?

Thoughts?

 -George

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