From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Xen Developer Summit BoF Notes : Seeding a Xen + Android / Embedded ecosystem BoF Date: Sat, 23 Nov 2013 18:01:24 +0100 Message-ID: <1385226084.21937.70.camel@Abyss> References: <528CF8AF.6010706@xen.org> <1385027533.10582.81.camel@Abyss> <528E0E81.7040104@xen.org> <1385104127.21937.10.camel@Abyss> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8507003046709830605==" 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: shyoo@os.korea.ac.kr Cc: lars.kurth@xen.org, "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============8507003046709830605== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-jo3zIxtD7NJed8lnVpky" --=-jo3zIxtD7NJed8lnVpky Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On sab, 2013-11-23 at 00:53 +0900, See-Hwan Yoo wrote: > Dear Faggioli and Lars,=20 >=20 Hi! Nice to talk to you here too... :-) > Thanks for putting me into the thread, I am eager to join here. >=20 Sure, BTW, have a look at this other one too, it's a lot related to this and even more to what you're talking about in this email of yours: http://bugs.xenproject.org/xen/mid/%3C1384802050.16918.219.camel@Solace%3E > My thought about real-time things are becoming clear, and here are > some. >=20 >=20 > 1. Simply running a real-time OS is definitely not enough for > guaranteeing deadline under virtualization. > 2. To support hard real-time over Xen, we need the followings: > a. WCET analysis for time-critical Xen services (hypcalls).=20 > Based upon this WCET, RTOS and apps (tasks) can calculate WCET, > accordingly. >=20 Yeah... WCET is particularly nasty, even in general, and virtualization would only make it even more of a nightmare! :-/ I agree that some need-to-be-certified / super-critical / ultra-hard real-time workload would need it, but at the same time I think there is a lot to improve before even getting close to that. Don't get me wrong, not that I object or won't be interested in someone wanting to do it, just a matter of priorities and of trying to start with the simple. :-) Speaking of RTOS on Xen, it would be nice to investigate whether there are someone that have been already ported... > b. Hierarchical scheduling theory buys you a real-time guarantee, and > what we want here is=20 > an interface and algorithm for finding VM (or vcpu) scheduling > parameters for rt schedulers (such as EDF or RM). > Of course we need a scheduler implementation (I think ARINC/SEDF > provides a basic format). >=20 Which is quite similar to what Sisu is saying in the other thread referenced above: http://bugs.xenproject.org/xen/mid/%3CCAPqOm-pz8jW3Dd2k9RWu3FFZi7rJTJpAbb6m= ACRWUXuY7eiFKQ@mail.gmail.com%3E And to which I agree too. :-) I'll avoid listing here some (more) research paper on how real-time hierarchical scheduling could be applied here... Perhaps I'll put them in the Wiki page. > d. Maximum latency guarantee for aperiodic/sporadic tasks (such as I/O > tasks) are difficult because =20 > We have to address scheduling model under split drivers. If > inter-VM scheduling latency is introduced,=20 > then the latency goes up to tens of milliseconds, which is > definitely not what we want. A possible simplification is=20 > prioritize the driver domain, however note that the driver domain > should run a real-time OS, instead of Linux.=20 > Yep, that would also be quite interesting. Perhaps we can actually start (at least for doing some measurements) with a real-time variant of Linux, either something like Xenomai or Linux+PREEMPT_RT patch and trheaded interrupt (and, of course, see how well threaded interrupt plays with our backends). > In addition, we should implement backend drivers (and physical > drivers) as real-time tasks. >=20 >=20 > 3. To support soft real-time over Xen, there are several studies out > there.=20 > However, most of them do not make code contribution. That is one > of key huddles.=20 >=20 Indeed. > I am specifically interested in bigLITTLE cpus as a means of > supporting soft real-time applications. However, I don't have time > schedules or written codes; so I just want to looking up when it > begins to get started.=20 >=20 Well, we'll surely have to cross that bridge at some point! > If you have another idea, please tell me.=20 > I am observing the lists, and would be glad if I can help it to make > progress. >=20 Cool... Let's see how these discussion evolve, and, sometime in the near future, if we can come up with a more concrete plan. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-jo3zIxtD7NJed8lnVpky 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 v1.4.15 (GNU/Linux) iEYEABECAAYFAlKQ32QACgkQk4XaBE3IOsTOaQCgjMDNMTW8XZxzju2VxRkpqrpc vBsAnj2J0h8gqEeAuNsSrA/+cNa87bE6 =vU4p -----END PGP SIGNATURE----- --=-jo3zIxtD7NJed8lnVpky-- --===============8507003046709830605== 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 --===============8507003046709830605==--