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: Wed, 27 Apr 2016 01:01:23 +0200 Message-ID: <1461711683.3525.122.camel@citrix.com> References: <1461657373.25541.26.camel@citrix.com> <571F8AB2.9010403@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5641137785525555645==" Return-path: Received: from mail6.bemta6.messagelabs.com ([85.158.143.247]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1avBze-00011f-Mg for xen-devel@lists.xenproject.org; Tue, 26 Apr 2016 23:02:10 +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 , George Dunlap Cc: George Dunlap , "xen-devel@lists.xenproject.org" List-Id: xen-devel@lists.xenproject.org --===============5641137785525555645== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8vieLWawhXuDL8fj2y/f" --=-8vieLWawhXuDL8fj2y/f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-04-26 at 16:00 -0400, Meng Xu wrote: > >=20 > > >=20 > > > The feature document template has been put together: > > > http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg01 > > > 929.html > > >=20 > > > And there are feature documents in tree already. > > >=20 > > > 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.=C2=A0=C2=A0Reading your e-m= ail, > > Dario, > > I might infer the following criteria: > >=20 > > 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. >=20 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. >=20 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. >=20 > 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? >=20 > Which one are we talking about here? (maybe item 1?) >=20 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 --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-8vieLWawhXuDL8fj2y/f 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 iEYEABECAAYFAlcf80MACgkQk4XaBE3IOsRwOACePZFUEAcYnabCvpy2WESFIFNa nBkAnRsPaELgZo1RYFXmHH2ieEfII5jm =JFph -----END PGP SIGNATURE----- --=-8vieLWawhXuDL8fj2y/f-- --===============5641137785525555645== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============5641137785525555645==--