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 -- <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/