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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Thu, 2017-09-28 at 00:52 +0100, Julien Grall wrote:
> On 09/28/2017 12:51 AM, Julien Grall wrote:
> > > 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.
> > 
> > Looking at the log I don't see any crash of Xen and it seems to
> > be responsive.
> 
> I forgot to add that I don't see any timeout on the guest console
> but can notice slow down (waiting for some PV device).
> 
Exactly! And in fact, I'm saying that, even if nothing breaks, maybe
there are intervals during which --due to the combination of the
overload, the non work-conserving nature and the fact that these CPUs
are slow-- Dom0 is slow in dealing with the backends, to the point that
OSSTest times out.

Then, after the "load spike", everything goes back to normal, the
system is responsive, the logs (like the runqueue dump you posted)
depicts a normal semi-idle system.

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: signature.asc
Description: This is a digitally signed message part

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