xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Lars Kurth <lars.kurth@xen.org>
To: Sisu Xi <xisisu@gmail.com>, Dario Faggioli <dario.faggioli@citrix.com>
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Roland Heusser <heusserr@mail.gvsu.edu>,
	Artem Mygaiev <artem.mygaiev@globallogic.com>,
	Lovene Bhatia <lbhatia@samsung.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Joshua Whitehead <whitehej@mail.gvsu.edu>,
	xen-devel <xen-devel@lists.xen.org>,
	Drek Darkover <wackerei@gmail.com>,
	Jeremiah Foster <jeremiah.foster@pelagicore.com>,
	Stefano Panella <stefano.panella@citrix.com>,
	Simon Martin <smartin@milliways.cl>,
	Nate Studer <nate.studer@dornerworks.com>,
	mdavis@planetaryresources.com
Subject: Re: Xen for real-time/embedded/automotive
Date: Wed, 20 Nov 2013 15:25:54 +0000	[thread overview]
Message-ID: <528CD482.90803@xen.org> (raw)
In-Reply-To: <CAPqOm-pz8jW3Dd2k9RWu3FFZi7rJTJpAbb6mACRWUXuY7eiFKQ@mail.gmail.com>


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

Adding a couple of off xen-devel people to the distribution list of this 
thread on request
Lars

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 <mailto: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/ <http://www.cse.wustl.edu/%7Exis/>
> 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


[-- Attachment #1.2: Type: text/html, Size: 11800 bytes --]

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

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

  reply	other threads:[~2013-11-20 15:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18 19:14 Xen for real-time/embedded/automotive Dario Faggioli
2013-11-19  1:27 ` Simon Martin
2013-11-20 14:04   ` Lars Kurth
2013-11-20 14:23     ` Simon Martin
2013-11-20 15:14       ` Lars Kurth
2013-11-20 17:36       ` Anil Madhavapeddy
2013-11-20 17:59         ` Simon Martin
2013-11-20 18:05           ` Anil Madhavapeddy
2013-11-20 18:35             ` Simon Martin
2013-11-28  9:53   ` Dario Faggioli
2013-11-28 11:39     ` Simon Martin
2013-11-28 12:03       ` Dario Faggioli
2013-11-28 12:39         ` Simon Martin
2013-11-30 11:37           ` Dario Faggioli
2013-11-20  4:50 ` Sisu Xi
2013-11-20 15:25   ` Lars Kurth [this message]
2013-11-21  7:04     ` Dario Faggioli
2013-11-21  7:52     ` Dario Faggioli
2013-12-12  8:05     ` Jeremiah Foster
2013-12-12  8:12       ` Dario Faggioli
2013-12-12  9:35         ` Lars Kurth
2013-12-12  9:39           ` Jeremiah Foster
2013-12-12  9:46             ` Dario Faggioli
2013-11-22  7:14 ` Dario Faggioli
2013-11-28  9:35 ` Dario Faggioli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=528CD482.90803@xen.org \
    --to=lars.kurth@xen.org \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=artem.mygaiev@globallogic.com \
    --cc=dario.faggioli@citrix.com \
    --cc=heusserr@mail.gvsu.edu \
    --cc=jeremiah.foster@pelagicore.com \
    --cc=lars.kurth@citrix.com \
    --cc=lbhatia@samsung.com \
    --cc=mdavis@planetaryresources.com \
    --cc=nate.studer@dornerworks.com \
    --cc=smartin@milliways.cl \
    --cc=stefano.panella@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wackerei@gmail.com \
    --cc=whitehej@mail.gvsu.edu \
    --cc=xen-devel@lists.xen.org \
    --cc=xisisu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).