Re: RTDS with extra time issue

From: Dario Faggioli <dfaggioli@suse.com>
To: Andrii Anisov <andrii_anisov@epam.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Meng Xu <xumengpanda@gmail.com>
Subject: Re: RTDS with extra time issue
Date: Fri, 16 Feb 2018 19:37:12 +0100	[thread overview]
Message-ID: <1518806232.3813.36.camel@suse.com> (raw)
In-Reply-To: <f4fdc887-3a67-386a-501a-c1f3b28aa980@epam.com>

[-- Attachment #1.1: Type: text/plain, Size: 3207 bytes --]

On Mon, 2018-02-12 at 20:44 +0200, Andrii Anisov wrote:
> Dario,
> 
Hi,

> On 12.02.18 12:20, Andrii Anisov wrote:
> > Actually as per Meng's explanation and calculations the problem was
> > on 
> > my side - wrong DomR task/VCPU parameters.
> > I was running the system with dummy loads and values received from 
> > CARTS and all seems to be ok (no deadline misses occured).
> 
> Well, what I expressed as dummy loads was all domains are generic
> armv8 
> kernels with minimal fs'es running `dd if=/dev/zero of=/dev/null`, 
> except DomR. In this case no DL misses occurred with parameters given
> by 
> CARTS.
> 
> Now I have real driver domain, Android with GPU sharing. Loads are
> like 
> youtube playback in DomA, dd from mmc through ssh in DomD. And I see 
> unexpected DL misses for the same RT configurations.
> 
And what is it that is running in DomR, the same thing as before, when
the load was synthetic? 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?

If the latter, are you sure the misses are not due to the fact that,
for instance, the rt app does not always behave as measured/expected,
when computing the parameters?

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

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.

Scheduling always as a consequence of some task/vcpu blocking, some
task/vcpu waking up, or of timer events, in all the OSes I have ever
seen, so I don't think Xen is really special wrt this.

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?

> This 
> seems to be not really fair and might be disruptive for RT
> scheduling.
> 
Well, if you're saying that accounting can be improved, I do agree. It
always can (again, in all the OSes! :-D)

Note that it is not always evident how to do that, and I'm not talking
about the actual implementation. I think it would not be too hard to
track the time we spend inside the hypervisor. But then, what do we
do? 

Because if DomX was running, and we entered Xen because an interrupt
arrived to deal with a timer or whatever from DomY, then I agree it's
not fair to charge DomX for that. But, OTOH, if we are in Xen because
DomX itself called an hypercall, then it is indeed ok to charge DomX.

And note that this does not have much to do with how schedule() gets
called. :-)

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