[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RT-Xen on ARM

On Tue, Jul 4, 2017 at 8:28 AM, Andrii Anisov <andrii_anisov@xxxxxxxx> wrote:
> On 03.07.17 21:42, Meng Xu wrote:
>> As far as I know, there is no known issue for ARM as long as that
>> version Xen runs on the ARM board.
>  That's good.
>> I assume you have your own workloads to run, which are periodically
>> activated task.
>> The workloads in [1] are independent periodic CPU-intensive tasks: the
>> task does some computation for every period.
>> If your workloads are similar to the tasks, it should be ok.
> Actually now we have just a high-level use case without any specific 
> parameters defined.
> I.e. in an automotive system there should be a domain dedicated to 
> instrumental cluster beside IVI domain. IC domain should be RT.
> So we are just evaluating and experimenting with an existing functionality.
>> One thing in my mind that may affect your evaluations for your real
>> workload is what you want to achieve.
>> The RTDS uses the EDF scheduling, under which the priorities of the
>> VCPUs (or VMs) are dynamically changed based on their (absolute)
>> deadlines. This provides better real-time performance for the
>> *overall* system.
> In case we would have a driver domain and IC domain would draw to pv display 
> baked by backend in a driver domain. Driver domain should be RT capable as 
> well.
> So it seems two domains should be RT beside non-RT IVI domain.
>> If you want to make one VM highest priority and let that VM preempt
>> other VMs whenever the highest priority VM is active, it's better to
>> use the RM or FP scheduling, instead of the EDF scheduling.
> So you are suggesting to introduce more RT schedulers with different 
> algorithms. Did I get you right?

The EDF scheduling cares about the overall system's RT performance. If
you want to guarantee the *soft* real-time performance of the IVI
domains and allow the IVI domain to delay the two RT domains in some
scheduling periods, the EDF scheduling is better than the RM
scheduling. Note that we need to reserve enough CPU resources to make
sure the delay from the IVI domain to the two RT domains won't cause
the deadline miss of the two RT domains.

The RM scheduling will guarantees a domain always has a higher
priority than another domain. If you want to eliminate the CPU delay
from the IVI domain to the other two RT domains, can tolerate some
deadline misses of the IVI domain, and want to consolidate the three
domains to *fewer* cores, the RM scheduling should be a better choice,

Supporting the RM scheduling policy in the RTDS scheduler is not
difficult. Actually, the RTDS scheduler was designed to be able to
extend to other scheduling policies, such as RM scheduling. In the
RT-Xen project[1], it supports both RM and EDF scheduling policy. We
just choose to upstream the EDF first.

Currently, we are working on synchronizing the RT-Xen with the latest
Xen: we want to implement the RM scheduling policy in the latest Xen.
I'm also teaching/training a master student how to implement the
scheduling policies in the RTDS scheduler so that we can have more

I personally am very interested in the realistic use case, especially
the automotive use cases, for the RTDS scheduler. If you have any use
case that we can help to test, please don't hesitate to ask.

[1] https://github.com/PennPanda/RT-Xen



Meng Xu
PhD Candidate in Computer and Information Science
University of Pennsylvania

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.