From: Andrii Anisov <andrii_anisov@epam.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Meng Xu <xumengpanda@gmail.com>
Subject: RTDS with extra time issue
Date: Fri, 9 Feb 2018 14:20:55 +0200 [thread overview]
Message-ID: <762ccb02-b758-1636-fddc-f4e6a3ca19d0@epam.com> (raw)
Dear Dario,
Now I'm experimenting with RTDS, in particular with "extra time"
functionality.
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
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.
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.
The ps in DomR is as following:
root@genericarmv8:~# ps
PID USER VSZ STAT COMMAND
1 root 1764 S init
2 root 0 SW [kthreadd]
3 root 0 SW [ksoftirqd/0]
4 root 0 SW [kworker/0:0]
5 root 0 SW< [kworker/0:0H]
6 root 0 SW [kworker/u2:0]
7 root 0 SW [rcu_preempt]
8 root 0 SW [rcu_sched]
9 root 0 SW [rcu_bh]
10 root 0 SW [migration/0]
11 root 0 SW< [lru-add-drain]
12 root 0 SW [watchdog/0]
13 root 0 SW [cpuhp/0]
14 root 0 SW [kdevtmpfs]
15 root 0 SW< [netns]
16 root 0 SW [kworker/u2:1]
17 root 0 SW [xenwatch]
18 root 0 SW [xenbus]
360 root 0 SW [khungtaskd]
361 root 0 SW [oom_reaper]
362 root 0 SW< [writeback]
364 root 0 SW [kcompactd0]
365 root 0 SWN [ksmd]
366 root 0 SW< [crypto]
367 root 0 SW< [kintegrityd]
368 root 0 SW< [bioset]
370 root 0 SW< [kblockd]
388 root 0 SW< [ata_sff]
394 root 0 SW [kworker/0:1]
433 root 0 SW< [watchdogd]
519 root 0 SW< [rpciod]
520 root 0 SW< [xprtiod]
548 root 0 SW [kswapd0]
549 root 0 SW< [vmstat]
633 root 0 SW< [nfsiod]
802 root 0 SW [khvcd]
844 root 0 SW< [bioset]
847 root 0 SW< [bioset]
850 root 0 SW< [bioset]
853 root 0 SW< [bioset]
856 root 0 SW< [bioset]
859 root 0 SW< [bioset]
861 root 0 SW< [bioset]
864 root 0 SW< [bioset]
946 root 0 SW< [vfio-irqfd-clea]
1405 root 2912 S {start_getty} /bin/sh /bin/start_getty 115200
hvc0 vt102
1406 root 2976 S /sbin/getty 38400 tty1
1407 root 3256 S -sh
1512 root 2908 S {st-trace-schedu} /bin/bash
/usr/sbin/st-trace-schedule -s m1
1523 root 1932 S rtspin -a 194000 -w 48 100 120
1527 root 1748 S /usr/sbin/ftcat -p /tmp/tmp.3PXDeo/cpu0.pid
/dev/litmus/sched_trace0 501 502 503 504 505 506 507 508 509 510 511
1533 root 3224 R ps
I noticed that behavior while running EPAM demo setup. Which consists of
HW drivers in DomD, PV Drivers backends in DomD, DomA running real
Android with PV Drivers and utilizing GPU sharing, etc.
But I managed to reproduce the issue when all domains are running
generic armv8 kernel with minimal initramfses.
So I suspect an issue in RTDS.
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next reply other threads:[~2018-02-09 12:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-09 12:20 Andrii Anisov [this message]
2018-02-09 12:25 ` RTDS with extra time issue Andrii Anisov
2018-02-09 13:18 ` Dario Faggioli
2018-02-09 15:03 ` Andrii Anisov
2018-02-09 15:18 ` Dario Faggioli
2018-02-09 15:36 ` Meng Xu
2018-02-09 15:56 ` Andrii Anisov
2018-02-09 17:51 ` Meng Xu
2018-02-10 0:14 ` Dario Faggioli
2018-02-10 4:53 ` Meng Xu
2018-02-12 10:17 ` Dario Faggioli
2018-02-12 11:08 ` Andrii Anisov
2018-02-12 14:52 ` Meng Xu
2018-02-12 10:38 ` Andrii Anisov
2018-02-12 10:20 ` Andrii Anisov
2018-02-12 18:44 ` Andrii Anisov
2018-02-16 18:37 ` Dario Faggioli
2018-02-20 11:34 ` Andrii Anisov
2018-02-22 17:53 ` Dario Faggioli
2018-02-26 12:00 ` Andrii Anisov
2018-02-09 15:34 ` Meng Xu
2018-02-09 15:53 ` Andrii Anisov
2018-02-09 16:04 ` Andrii Anisov
2018-02-09 17:53 ` Meng Xu
2018-02-09 18:07 ` Andrii Anisov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=762ccb02-b758-1636-fddc-f4e6a3ca19d0@epam.com \
--to=andrii_anisov@epam.com \
--cc=dario.faggioli@citrix.com \
--cc=xen-devel@lists.xenproject.org \
--cc=xumengpanda@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.