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 00:49:50 +0200 Message-ID: <1461710990.3525.111.camel@citrix.com> References: <1461657373.25541.26.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8295743312043070141==" 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 1avBnp-00089n-Mt for xen-devel@lists.xenproject.org; Tue, 26 Apr 2016 22:49:57 +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 Cc: George Dunlap , "xen-devel@lists.xenproject.org" List-Id: xen-devel@lists.xenproject.org --===============8295743312043070141== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5uYASO+XLF7MNcVHYdFD" --=-5uYASO+XLF7MNcVHYdFD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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? >=20 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=C2=A0=C2=A0between the scheduler's complexity= and > the benefit brought by introducing complexity. >=20 > 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. >=20 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. >=20 > 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. >=20 > What do you think? >=20 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. > >=20 > > 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 --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-5uYASO+XLF7MNcVHYdFD 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 iEYEABECAAYFAlcf8I8ACgkQk4XaBE3IOsTnJQCfUuD/Gka4YlTtx/J0rQqsGlTG 0wkAn3/LxNpJzJJTc6aVcT6soQH1uusX =cwf7 -----END PGP SIGNATURE----- --=-5uYASO+XLF7MNcVHYdFD-- --===============8295743312043070141== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============8295743312043070141==--