From: Dario Faggioli <dfaggioli@suse.com>
To: Meng Xu <xumengpanda@gmail.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Andrii Anisov <andrii_anisov@epam.com>
Subject: Re: RTDS with extra time issue
Date: Mon, 12 Feb 2018 11:17:18 +0100 [thread overview]
Message-ID: <1518430638.16540.17.camel@suse.com> (raw)
In-Reply-To: <CAENZ-+k63FbKdfvaxxEb9UD0F=BQ-g=f1d=uR_VEEOBHr262Dg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1389 bytes --]
On Fri, 2018-02-09 at 23:53 -0500, Meng Xu wrote:
> >
> > Perhaps Meng has some more ideas on this as well. :-)
>
> If the RT VCPU has only one RT task on it, we can synchronize the
> release time of the VCPU and that of the RT task. In other words, the
> release offset of both the VCPU and the RT task are the same in terms
> of the wall clock. Then we can assign the task's parameter to the
> VCPU
> and guarantee the task has no deadline miss if the VCPU has no
> deadline miss.
> However, this observation only works when the assumption that one
> VCPU
> has only one task in the RT domain. I'm not sure how practical it is
> because the observation cannot be generalized for multiple tasks on
> one VCPU.
>
> Andrii and Dario,
> Do you think the assumption that one VCPU runs only one RT task is
> reasonable in practice?
> If it is, is there some use cases for this assumption?
>
Well, I'll let Andrii reply, but honestly, I don't think it is.
See, for instance, the fact that DomR has only 1 vCPU, so I find it
unlikely that the only thing that run there is *just* *one* real-time
task. :-/
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
next prev parent reply other threads:[~2018-02-12 10:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-09 12:20 RTDS with extra time issue Andrii Anisov
2018-02-09 12:25 ` 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 [this message]
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=1518430638.16540.17.camel@suse.com \
--to=dfaggioli@suse.com \
--cc=andrii_anisov@epam.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).