From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v1 1/4] xen: add real time scheduler rt Date: Fri, 5 Sep 2014 11:36:36 +0200 Message-ID: <1409909796.2673.256.camel@Solace.lan> References: <1408921125-21470-1-git-send-email-mengxu@cis.upenn.edu> <1408921125-21470-2-git-send-email-mengxu@cis.upenn.edu> <1409763450.2673.140.camel@Solace.lan> <1409840858.2673.224.camel@Solace.lan> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7483489105598957051==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Meng Xu Cc: Ian Campbell , Sisu Xi , Stefano Stabellini , George Dunlap , Chenyang Lu , Ian Jackson , "xen-devel@lists.xen.org" , Linh Thi Xuan Phan , Meng Xu , Jan Beulich , Chao Wang , Chong Li , Dagaen Golomb List-Id: xen-devel@lists.xenproject.org --===============7483489105598957051== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-kwIp5ESFSVRkcm0qtjSJ" --=-kwIp5ESFSVRkcm0qtjSJ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On gio, 2014-09-04 at 11:30 -0400, Meng Xu wrote: >=20 >=20 > 2014-09-04 10:27 GMT-04:00 Dario Faggioli : > > > For instance, I can put, in an SMP guest, two real-time > applications > > > with different timing requirements, and pin each one to a > different > > > (v)cpu (I mean pin *inside* the guest). At this point, I'd > like for each > > > vcpu to have a set of RT scheduling parameters, at the Xen > level, that > > > matches the timing requirements of what's running inside. > > > > > > This may not look so typical in a server/cloud > environment, but can > > > happen (at least in my experience) in a mobile/embedded > env. > > > > But to play devil's advocate for a minute here: > > > =20 > Hehe, please, be my guest! :-D :-D > =20 > > couldn't you just put > > them in two different single-vcpu VMs then? > > > =20 >=20 >=20 > =E2=80=8BWell, let me give a simpler example: > Suppose we have three tasks in one VM, each task has period 4ms and > budget =E2=80=8B6ms (its utilization is 2/3). > You mean budget=3D4ms and period=3D6ms, don't you? :-) > If all these three tasks starts execution at the same time, we can > use two full-capacity vcpus (200% capacity cpu resource) to schedule > these three tasks.=20 > However if you want to get two VMs, each of which has a full capacity > vcpu (100% capacity cpu), we cannot schedule these three tasks, > because one tasks cannot (well, at least very hard) migrate from one > VM to another.=20 >=20 But... In this case, in the former configuration (1 VM with 2 vcpus), each vcpu would (or at least can) have the same bandwidth of 100%, i.e., the same parameters... or am I missing something? What we're tying to assess here, is the usefulness of the possibility of setting _different_ parameters (and hence different pcpu bandwidth) for each vcpu. Also, it looks like you're assuming to have a real-time scheduler inside the VM, which may or may not be the case. > =E2=80=8BThis is just a simple example, we could of course have an exampl= e > like this but the vcpus are not full-capacity vcpus. :-) >=20 Yeah, well, perhaps it's a bit too simple. :-D Don't get me wrong, I continue thinking per-vcpu params is something we really want, it's just the example I'm not sure I'm getting/liking. I still think the example of multiple, concurrent and strictly related activities having different timing requirements to be a really sensible one. In fact, in that case, especially if one does not have a real-time scheduler inside the guest, mapping those requirements on the Xen scheduler is the easier (only?) way to port the app from baremetal to virtual machine! Regards, Dario PS. BTW, Meng, can you use plain text emails when sending to the list? --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-kwIp5ESFSVRkcm0qtjSJ 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 iEYEABECAAYFAlQJhCQACgkQk4XaBE3IOsRQXwCgg4dD+DbMnb6Dr6qpqApkhZ0p hpkAn05Fr8JpGZu6KczEtGC89eniSgEr =TjVS -----END PGP SIGNATURE----- --=-kwIp5ESFSVRkcm0qtjSJ-- --===============7483489105598957051== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7483489105598957051==--