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/
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xenfirstname.lastname@example.org https://lists.xenproject.org/mailman/listinfo/xen-devel