From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Should we mark RTDS as supported feature from experimental feature? Date: Tue, 26 Apr 2016 09:56:13 +0200 Message-ID: <1461657373.25541.26.camel@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5456793909355726744==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1auxr4-0004M0-1S for xen-devel@lists.xenproject.org; Tue, 26 Apr 2016 07:56:22 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Meng Xu , "xen-devel@lists.xenproject.org" Cc: George Dunlap List-Id: xen-devel@lists.xenproject.org --===============5456793909355726744== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZF5gm5+dpoidasnh7qZV" --=-ZF5gm5+dpoidasnh7qZV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-04-25 at 21:44 -0400, Meng Xu wrote: > Hi Dario and all, >=20 Hi, > When RTDS scheduler is initialized, it will print out that the > scheduler is an experimental feature with the following lines: >=20 > =C2=A0=C2=A0=C2=A0=C2=A0printk("Initializing RTDS scheduler\n" >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"WARNIN= G: This is experimental software in development.\n" >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Use at= your own risk.\n"); >=20 > On RTDS' wiki [1], it says the RTDS scheduler is experimental > feature. >=20 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). >=20 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? >=20 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? >=20 > Please correct me if I'm wrong. >=20 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! :-) Regards, Dario --- <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-ZF5gm5+dpoidasnh7qZV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlcfHx4ACgkQk4XaBE3IOsQP1wCeMXh68PcS5Tgru/JNyQKxRkiy m1YAn3jrBhicy7x2UuezL5GZG2jAf1tt =tqtj -----END PGP SIGNATURE----- --=-ZF5gm5+dpoidasnh7qZV-- --===============5456793909355726744== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============5456793909355726744==--