All of lore.kernel.org
 help / color / mirror / Atom feed
From: Meng Xu <xumengpanda@gmail.com>
To: Dario Faggioli <dfaggioli@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Andrii Anisov <andrii_anisov@epam.com>
Subject: Re: RTDS with extra time issue
Date: Fri, 9 Feb 2018 23:53:19 -0500	[thread overview]
Message-ID: <CAENZ-+k63FbKdfvaxxEb9UD0F=BQ-g=f1d=uR_VEEOBHr262Dg@mail.gmail.com> (raw)
In-Reply-To: <1518221652.4261.33.camel@suse.com>

>
> It looks like DomR's vCPU does get 50% of CPU time, so it's not that
> other vCPUs are preventing it to exploit all its own reservation. If
> that would have not been the case, there'd be a bug in the scheduler.
>
> By giving the vCPU 100% (either via "budget == period" or with
> extratime), we will figure out if the real-time applications inside can
> actually meet their deadline. If they can't even with such setup, it
> would mean the problem is somewhere else (virtualization overhead, IRQ
> latency, etc).
>
> If the applications can meet their deadline with 100% CPU time, but not
> with 50%, then there are two possibilities:
> 1) they need more than 50%;
> 2) you're having "period synchronization" issues, as Meng was
> describing.
>
> Figuring out if you're on 1, should be as easy as trying to five DomR
> 55%, then 60%, then 65%, etc. And see when it happens that the deadline
> misses are gone forever and for good.
>
> If you can't get rid of deadline misses, it probably means you are in
> case 2, and you need to find a way to make sure that your real-time
> applications inside the domain are able to actually exploit the
> domain's vCPU's budget when it's there. I.e., you don't want them to
> activate when the budget is about to finish, and hence suffer from the
> "blackout" shown in Meng's diagram.
>
> Unfortunately, that's not really trivial to do. If the workload is
> really periodic, it may be enough to find a way to do some kind of
> "calibration" at the beginning. But I'm not sure how robust this will
> actually be.
>
> 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?

Thanks,

Meng

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

  reply	other threads:[~2018-02-10  4:54 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 [this message]
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='CAENZ-+k63FbKdfvaxxEb9UD0F=BQ-g=f1d=uR_VEEOBHr262Dg@mail.gmail.com' \
    --to=xumengpanda@gmail.com \
    --cc=andrii_anisov@epam.com \
    --cc=dfaggioli@suse.com \
    --cc=xen-devel@lists.xenproject.org \
    /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.