Re: [Xen-devel] RTDS with extra time issue

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Fri, 2018-02-09 at 12:51 -0500, Meng Xu wrote:
> > On 09.02.18 17:36, Meng Xu wrote:
> > > Another way to check if there is interference from services in
> > > domR is
> > > to set period = budget for the domR's VCPUs.
> > 
> > Could you please explain how setting budget equal to period would
> > help
> > discover any interferences from services in the domain?
> > 
> Basically, setting period = budget is similar to what Dario suggests.
>
The goal is to figure out where the problem is.

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. :-)

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
Description: This is a digitally signed message part

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