Re: [Xen-devel] Xen Developer Summit BoF Notes : Seeding a Xen + Android / Embedded ecosystem BoF

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On sab, 2013-11-23 at 00:53 +0900, See-Hwan Yoo wrote:
> Dear Faggioli and Lars, 
> 
Hi! Nice to talk to you here too... :-)

> Thanks for putting me into the thread, I am eager to join here.
> 
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.
> 
> 
> 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). 
>     Based upon this WCET, RTOS and apps (tasks) can calculate WCET,
> accordingly.
> 
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 
>     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).
> 
Which is quite similar to what Sisu is saying in the other thread
referenced above:

http://bugs.xenproject.org/xen/mid/%3CCAPqOm-pz8jW3Dd2k9RWu3FFZi7rJTJpAbb6mACRWUXuY7eiFKQ@xxxxxxxxxxxxxx%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  
>     We have to address scheduling model under split drivers. If
> inter-VM scheduling latency is introduced, 
>     then the latency goes up to tens of milliseconds, which is
> definitely not what we want. A possible simplification is 
>     prioritize the driver domain, however note that the driver domain
> should run a real-time OS, instead of Linux. 
>
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.
> 
> 
> 3. To support soft real-time over Xen, there are several studies out
> there. 
>     However, most of them do not make code contribution. That is one
> of key huddles. 
> 
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. 
> 
Well, we'll surely have to cross that bridge at some point!

> If you have another idea, please tell me. 
> I am observing the lists, and would be glad if I can help it to make
> progress.
> 
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

-- 
<<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: signature.asc
Description: This is a digitally signed message part

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