|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RTDS with extra time issue
On Fri, 2018-02-09 at 14:20 +0200, Andrii Anisov wrote: > Dear Dario, > Hi, > My experimental setup is built on Salvator-X board with H3 SOC > (running > only big cores cluster, 4xA57). > Domains up and running, and their VCPU are as following: > > root@generic-armv8-xt-dom0:/xt/dom.cfg# xl sched-rtds -v all > Cpupool Pool-0: sched=RTDS > Name ID VCPU Period Budget > Extratime > (XEN) FLASK: Allowing unknown domctl_scheduler_op: 3. > Domain-0 0 0 10000 1000 yes > Domain-0 0 1 10000 1000 yes > Domain-0 0 2 10000 1000 yes > Domain-0 0 3 10000 1000 yes > (XEN) FLASK: Allowing unknown domctl_scheduler_op: 3. > DomR 3 0 10000 5000 no > (XEN) FLASK: Allowing unknown domctl_scheduler_op: 3. > DomA 5 0 10000 1000 yes > DomA 5 1 10000 1000 yes > DomA 5 2 10000 1000 yes > DomA 5 3 10000 1000 yes > (XEN) FLASK: Allowing unknown domctl_scheduler_op: 3. > DomD 6 0 10000 1000 yes > DomD 6 1 10000 1000 yes > DomD 6 2 10000 1000 yes > DomD 6 3 10000 1000 yes > Ok, so you're giving: - 40% CPU time to Domain-0 - 50% CPU time to DomR - 40% CPU time to DomA - 40% CPU time to DomD total utilization is 170%. As far as I've understood you have 4 CPUs, right? If yes, there *should* be no problems. (Well, in theory, we'd need a schedulability test to know for sure whether the system is "feasible", but I'm going to assume that it sort of is, and leave to Meng any further real-time scheduling analysis related configurations. :-) ). > The idea of such configuration is that only DomR really runs RT > tasks, > and their CPU utilization would be less than half a CPU. Rest of the > domains are application domains without need of RT guarantees for > their > tasks, but can utilize as much CPU as they need and is available at > this > moment. > So, this should work, as allowing the other domains to use extratime should *not* allow them to prevent DomR to get it's 50% share of CPU time. I wonder, though, if this case would not be better if cpupools are used. E.g., you can leve the non real-time domains in the default pool (and have Credit or Credit2 there), and then have an RTDS cpupool in which you put DomR, with its 50% share, and perhaps someone else (just to avoid wasting the other 50%). But that's a different story... > I load application domains with `dd if=/dev/zero of=/dev/null` per > VCPU. > In DomR I run one RT task with period 10ms and wcet 4ms (I'm using > LITMUS-RT for DomR), and see that this task sometime misses its > deadline. Which means that the only VCPU of DomR haven't got its 5ms > each 10ms. > Well, that's a possibility, and (if the system is indeed schedulable, which again, I'm assuming just out of laziness :-/ ) it would be a bug. However, as a first thing, I'd make sure that this is actually not happening. Basically, can you also fully load (like with dd as above, or just yes or while(1)) DomR, and then check if it is getting 50%? For a first approximation of this, you can check with xentop. If you want to be even more sure/you want to know it precisely, you can use tracing. If DomR is not able to get its share, then we have an issue/bug in the scheduler. If it does, then the scheduler is doing its job, and the issue may be somewhere else (e.g., something inside the guest may eat some of the budget, in such a way that not all of it is available when you actually need it). Let me know. Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |