Re: Xen for real-time/embedded/automotive

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 8195 bytes --]

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
> 
And I'm doing the same with Thomas.

Dario

> On 20/11/2013 04:50, Sisu Xi wrote:
> 
> > Hi, Dario: 
> > 
> > 
> > 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.
> > 
> > 
> > 1. A real-time CPU scheduler would be great. That's actually the
> > motivation that we started the RT-Xen project.
> > 
> > 
> > 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:
> > 
> > 
> > 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.
> > 
> > 
> > 
> > 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.
> > 
> > 
> > They can be found at RT-Xen
> > website: https://sites.google.com/site/realtimexen/publications
> > 
> > 
> > 2. An appropriate cache management scheme would be great.
> > Current CPU architecture have both dedicated cache (usually L1 and
> > L2) and shared cache (L3).
> > 
> > 
> > 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.
> > 
> > 
> > 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. 
> > <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. 
> > <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=&arnumber=5207888&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5207888
> > 
> > http://link.springer.com/article/10.1007%2Fs11704-012-2099-6
> > 
> > 
> > 
> > 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.
> > 
> > 
> > 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. 
> > 
> > 
> > We are working on the actual network traffic through NIC now.
> > 
> > 
> > Thanks and I'd love to hear any feedback/comments/suggestions on
> > RT-Xen.
> > 
> > 
> > Sisu
> > 
> > 
> > 
> > 
> > 
> > 
> > On Mon, Nov 18, 2013 at 1:14 PM, Dario Faggioli
> > <dario.faggioli@citrix.com> wrote:
> >         Hello everyone,
> >         
> >         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.
> >         
> >         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.
> >         
> >         So, if you work in embedded/automotive/aerospace/..., what
> >         are you
> >         requirements? How can we improve Xen (on ARM) for your use
> >         case?
> >         
> >         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!
> >         
> >         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).
> >         
> >         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
> >         
> >         Here they are some (more) links:
> >         
> >          - 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-presentation2013v7dualandroid
> >         
> >         http://www.youtube.com/watch?v=Km6gBnIqaWo&feature=youtu.be
> >           *
> >         http://www.slideshare.net/xen_com_mgr/xen-in-oss-based-in-vehicle-infotainment-systems
> >         
> >         http://www.youtube.com/watch?v=po1IeElg8tg&feature=youtu.be
> >         
> >          - The Real-Time Xen project Sisu is working on:
> >           * https://sites.google.com/site/realtimexen/
> >         
> >         Looking forward to hearing from you!
> >         
> >         Thanks and Regards,
> >         Dario
> >         
> >         --
> >         <<This happens because I choose it to happen!>> (Raistlin
> >         Majere)
> >         -----------------------------------------------------------------
> >         Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> >         Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge
> >         (UK)
> >         
> > 
> > 
> > 
> > 
> > -- 
> > Sisu Xi, PhD Candidate
> > 
> > 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 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel