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

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Tue, 2018-02-20 at 13:34 +0200, Andrii Anisov wrote:
> Hello Dario,
> 
Hi,

> On 16.02.18 20:37, Dario Faggioli wrote:
> > And in any case, is it, in its turn (I mean the
> > workload running in DomR) a synthetic real-time load, or is it a
> > real
> > real-time application?
> 
> Real-time domain is synthetic, though. I'm using LITMUS-RT system
> for 
> the DomR. In particular with amount of work based configuration [1] 
> introduced recently.
> 
Ah, nice! :-)

> Even for the synthetic rt workload some deviations in execution time
> are 
> noticed (~0.5%). But with no IRQ extensive load in application
> domains, 
> no DL misses are noticed in RT domain.
> 
Ok, I see.

> > > Well this provides some ground for another my concern about XEN
> > > scheduling approach. My doubt is that scheduling is done within
> > > softirq,
> > > so all time spent with pcpu for exception itself and possible
> > > timer
> > > actions is accounted for the vcpu which context was interrupted.
> > 
> > I am not sure I fully understand this.
> 
> My idea is to charge time spent in hypervisor from current vcpu
> budget, 
> except serving that vcpu hypercalls and handling interrupts targeted 
> current vcpu. Same as you expressed:
> 
As I said already, improving the accounting would be more than welcome.
If you're planning on doing something like this already, I'll be happy
to look at the patches. :-)

> > If you're worried about some kind of overhead may be consuming some
> > of
> > your real-time reservation, try to increase the reservation itself
> > a
> > bit, and see if the misses disappear.
> 
> Its not about overhead but unfair time accounting. And this
> unfairness 
> is pretty arbitrary, depends on other domains activity.
> 
Sure, I agree it's pretty bad. It's indeed particularly bad for RTDS,
where it messes with guarantees, but it's rather bad for other
schedulers as well, as it messed with fairness.

> > One difference could be that Linux can be configured to be fully
> > preemptible --even the kernel-- while Xen is not. But I don't think
> > this is what you're hinting at, is it?
> 
> No, it is not.
>
Ok, I was just double checking.

> If we are speaking about Linux, it much closer to 
> CONFIG_IRQ_TIME_ACCOUNTING [1].
> 
Yes, I'm familiar with that. That exact same model can't be applied to
Xen, but at least tracking time spent in IRQ handling, and discounting
that from vCPU execution time, should not be too hard.

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