Re: RTDS with extra time issue

[Dario Faggioli <dfaggioli@suse.com>]

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

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel