Re: Guest start issue on ARM (maybe related to Credit2) [Was: Re: [xen-unstable test] 113807: regressions - FAIL]

[Dario Faggioli <dario.faggioli@citrix.com>]

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

On Tue, 2017-09-26 at 18:28 +0100, Julien Grall wrote:
> On 09/26/2017 08:33 AM, Dario Faggioli wrote:
> > > 
> > Here's the logs:
> > http://logs.test-lab.xenproject.org/osstest/logs/113816/test-armhf-
> > armhf-xl-rtds/info.html
> 
> It does not seem to be similar, in the credit2 case the kernel is
> stuck at very early boot.
> Here it seems it is running (there are grants setup).
> 
Yes, I agree, it's not totally similar.

> This seem to be confirmed from the guest console log, I can see the
> prompt. Interestingly
> when the guest job fails, it has been waiting for a long time disk
> and hvc0. Although, it
> does not timeout.
> 
Ah, I see what you mean, I found it in the guest console log.

> I am actually quite surprised that we start a 4 vCPUs guest on a 2
> pCPUs platform. The total of
> vCPUs is 6 (2 DOM0 + 4 DOMU). The processors in are not the greatest
> for testing. So I was
> wondering if we end up to have too many vCPUs running on the platform
> and making it unreliable
> the test?
> 
Well, doing that, with this scheduler, is certainly *not* the best
recipe for determinism and reliability.

In fact, RTDS is a non-work conserving scheduler. This means that (with
default parameters) each vCPU gets at most 40% CPU time, even if there
are idle cycles.

With 6 vCPU, there's a total demand of 240% of CPU time, and with 2
pCPUs, there's at most 200% of that, which means we're in overload
(well, at least that's the case if/when all the vCPUs try to execute
for their guaranteed 40%).

Things *should really not* explode (like as in Xen crashes) if that
happens; actually, from a scheduler perspective, it should really not
be too big of a deal (especially if the overload is transient, like I
guess it should be in this case). However, it's entirely possible that
some specific vCPUs failing to be scheduler for a certain amount of
time, causes something _inside_ the guest to timeout, or get stuck or
wedged, which may be what happens here.

I'm adding Meng to Cc, to see what he thinks about this situation.

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel