|
[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, IMO. 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 contributors. 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 Best, Meng ----------- Meng Xu PhD Candidate in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |