From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Xen for real-time/embedded/automotive Date: Thu, 21 Nov 2013 08:52:36 +0100 Message-ID: <1385020356.10582.44.camel@Abyss> References: <1384802050.16918.219.camel@Solace> <528CD482.90803@xen.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2619127701642827392==" Return-path: In-Reply-To: <528CD482.90803@xen.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: lars.kurth@xen.org Cc: Lars Kurth , Roland Heusser , Artem Mygaiev , Lovene Bhatia , Sisu Xi , Stefano Stabellini , George Dunlap , Joshua Whitehead , xen-devel , Drek Darkover , Thomas Taranowski , Jeremiah Foster , mdavis@planetaryresources.com, Simon Martin , Nate Studer , Stefano Panella List-Id: xen-devel@lists.xenproject.org --===============2619127701642827392== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-z+85Cm9kXiAultuMPSN4" --=-z+85Cm9kXiAultuMPSN4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mer, 2013-11-20 at 15:25 +0000, Lars Kurth wrote: > Adding a couple of off xen-devel people to the distribution list of > this thread on request > Lars >=20 And I'm doing the same with Thomas. Dario > On 20/11/2013 04:50, Sisu Xi wrote: >=20 > > Hi, Dario:=20 > >=20 > >=20 > > Thanks for starting this topic. I have limited experience with > > industry, so I'll provide some input from the academia side. Please > > correct me if I am wrong. > >=20 > >=20 > > 1. A real-time CPU scheduler would be great. That's actually the > > motivation that we started the RT-Xen project. > >=20 > >=20 > > The scheduling in a virtualized environments maps to a two-level > > scheduling hierarchy in real-time systems. We can use the > > hierarchical scheduling theories to provide formal analysis for it. > > One key assumption of these theories is a formally defined 'server' > > to represent the VCPUs. We implemented and compared different > > servers in RT-Xen. and published at: > >=20 > >=20 > > S. Xi, J. Wilson, C. Lu and C.D. Gill, RT-Xen: Towards Real-time > > Hypervisor Scheduling in Xen, ACM International Conference on > > Embedded Software (EMSOFT'11), October 2011. > >=20 > >=20 > >=20 > > J. Lee, S. Xi, S. Chen, L.T.X. Phan, C. Gill, I. Lee, C. Lu and O. > > Sokolsky, Realizing Compositional Scheduling through Virtualization, > > IEEE Real-Time and Embedded Technology and Applications Symposium > > (RTAS'12), April 2012. > >=20 > >=20 > > They can be found at RT-Xen > > website: https://sites.google.com/site/realtimexen/publications > >=20 > >=20 > > 2. An appropriate cache management scheme would be great. > > Current CPU architecture have both dedicated cache (usually L1 and > > L2) and shared cache (L3). > >=20 > >=20 > > a) For the dedicated cache, existing credit1 use partitioned > > scheduling with load-balancing; while credit2 use modified global > > scheduling with migration resistant/compensation. I think if the > > user runs cache-sensitive application, partitioned scheduler seems > > to be a better choice. > >=20 > >=20 > > b) For the shared cache, the 'noisy neighbor' problem where one > > guest OS just runs a cache-busy application and everybody hurts can > > happen. I have seen several papers try to solve it, but don't know > > whether they will be integrated into Xen or not.=20 > > <1> If there are multiple LLC, each shared by a subset of PCPUs, a > > dynamic cluster scheme is proposed in this paper: > > Min Lee, Karsten Schwan. "Region Scheduling: Efficiently Using the > > Cache Architectures via Page-level Affinity." ASPLOS 2012, London, > > UK, March 3-7, 2012.=20 > > <2> If there is one large shared LLC, cache partition by domain > > seems a solution. These two papers have explored it: > > http://ieeexplore.ieee.org/xpl/login.jsp?tp=3D&arnumber=3D5207888&url= =3Dhttp%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D52078= 88 > >=20 > > http://link.springer.com/article/10.1007%2Fs11704-012-2099-6 > >=20 > >=20 > >=20 > > 3. An deterministic network latency through Domain-0 would be great. > > Currently Xen does not support packet prioritization. Users can > > achieve similar function by using the Linux Traffic Control Tool in > > Domain-0, but priority-inversion can still happen. > >=20 > >=20 > > We did some work on prioritizing inter-domain communication on Xen, > > and published at: > > S. Xi, C. Li, C. Lu and C. Gill, Prioritizing Local Inter-Domain > > Communication in Xen, ACM/IEEE International Symposium on Quality of > > Service (IWQoS'13), June 2013.=20 > >=20 > >=20 > > We are working on the actual network traffic through NIC now. > >=20 > >=20 > > Thanks and I'd love to hear any feedback/comments/suggestions on > > RT-Xen. > >=20 > >=20 > > Sisu > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > On Mon, Nov 18, 2013 at 1:14 PM, Dario Faggioli > > wrote: > > Hello everyone, > > =20 > > So, looking at the last Xen Developer Summit, other > > co-located and > > previous conferences, as well as here on the list, there > > appears to be a > > booming interest in running Xen on embedded systems of > > various kind. > > =20 > > This mail to say that: > > * we're ready to take up the challenge! :-) > > * in doing that, we really are interested in everyone's > > collaboration > > or, at very least, feedback. > > =20 > > So, if you work in embedded/automotive/aerospace/..., what > > are you > > requirements? How can we improve Xen (on ARM) for your use > > case? > > =20 > > Personally, I'm mostly interested on the scheduling, latency > > and, in > > general, real-time angle. So whether it is on and Android > > phone/tablet, > > an in-car infotinement system, an audio workstation or a > > rocket that you > > want to run Xen, tell me/us what you need in terms of > > increased > > determinism and decreased latencies! > > =20 > > For instance, I think it would be nice to start with some > > measurements: > > http://wiki.xenproject.org/wiki/Xen_Development_Projects#Is_Xen= _ready_for_the_Real-Time.2FEmbedded_World.3F > > That would basically mean running some latency oriented > > benchmarks both > > in Dom0 and in a guest(s), and compare the result with bare > > metal. > > It would be similar to what Open Source Automation > > Development Lab > > (OSADL) people do on "latency QA farm". Actually, how could > > would it be > > to be able to get in touch with them and have Xen run in > > there? (They > > already do something virt-related, but it's very limited). > > =20 > > https://www.osadl.org/QA-Farm-Realtime.qa-farm-about.0.html > > https://www.osadl.org/Real-time-host-and-kvm-virtualization.qa-= farm-rt-host-and-kvm.0.html > > =20 > > Here they are some (more) links: > > =20 > > - Presentations (from Lovene and Artem) of Xen on some > > typical embedded > > systems (Android tablet and in-car infotinement) > > * > > http://www.slideshare.net/xen_com_mgr/sruk-xen-presentation2013= v7dualandroid > > =20 > > http://www.youtube.com/watch?v=3DKm6gBnIqaWo&feature=3Dyoutu.be > > * > > http://www.slideshare.net/xen_com_mgr/xen-in-oss-based-in-vehic= le-infotainment-systems > > =20 > > http://www.youtube.com/watch?v=3Dpo1IeElg8tg&feature=3Dyoutu.be > > =20 > > - The Real-Time Xen project Sisu is working on: > > * https://sites.google.com/site/realtimexen/ > > =20 > > Looking forward to hearing from you! > > =20 > > 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) > > =20 > >=20 > >=20 > >=20 > >=20 > > --=20 > > Sisu Xi, PhD Candidate > >=20 > > http://www.cse.wustl.edu/~xis/ > > Department of Computer Science and Engineering > > Campus Box 1045 > > Washington University in St. Louis > > One Brookings Drive > > St. Louis, MO 63130=20 > >=20 > >=20 > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-z+85Cm9kXiAultuMPSN4 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) iEYEABECAAYFAlKNu8QACgkQk4XaBE3IOsQ8xACfbVOZmPmtBOgvyqy1tfDNt1zo Ub4AoIizdhsfNB3A+i9Ze1NBoqVdvIFZ =v0g7 -----END PGP SIGNATURE----- --=-z+85Cm9kXiAultuMPSN4-- --===============2619127701642827392== 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 --===============2619127701642827392==--