From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Guest start issue on ARM (maybe related to Credit2) [Was: Re: [xen-unstable test] 113807: regressions - FAIL] Date: Thu, 28 Sep 2017 11:38:55 +0200 Message-ID: <1506591535.5001.2.camel@citrix.com> References: <1506348460.27663.3.camel@citrix.com> <1506411226.27663.28.camel@citrix.com> <1506459110.27663.41.camel@citrix.com> <7fa4f13e-c4fe-cb7e-0438-f2f170c948bb@arm.com> <4143b0c0-18c7-4758-d3a5-1be4b0669dbb@arm.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1452918427421707408==" Return-path: In-Reply-To: <4143b0c0-18c7-4758-d3a5-1be4b0669dbb@arm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Julien Grall , osstest service owner , xen-devel@lists.xensource.com Cc: Stefano Stabellini , Meng Xu List-Id: xen-devel@lists.xenproject.org --===============1452918427421707408== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-vIkqAKTmQv2NBH0MEzQN" --=-vIkqAKTmQv2NBH0MEzQN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. > >=20 > > Looking at the log I don't see any crash of Xen and it seems to > > be responsive. >=20 > 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). >=20 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 --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-vIkqAKTmQv2NBH0MEzQN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJZzMMvAAoJEBZCeImluHPuSxUP/3ex5X/JHoUqbrXk9kgkIU/5 zmYmhykRyKI25+WO5Bd4ZVnbp+NOEam6bTvk401kb1dvQs4gid28FDK42gtJPjgW j3VgMxySqzgU6r7U6AeRCte25qBF7sBpqmvkJ0SptyYsAJ7qLi9RkrIrlETLFO5e gbhu397PTSLlzY2eQ4Sx8jY4XzV44reXom7E8HP+QS5sHFCVXvb5tf7Dbo08bHjS 1gAPZmzUW1jHe3fYmn90TiMc/sufpOm8oeAbh4VEpRyu7KfMYEZpG/NFVg2g97Cj YoJbUsj09t5ZRIIPwnrwwfIgenwM8CKtuuxenPbB6dctw587lttIysLg1ByV6poq kxqd7yG2Ze1Iu1eO4QleWwA0hHwNyDw2e18m5dod3ZUwbvK487YNlOViLDhtux/L GmZNKdSk8LpphxLaLvpb13UJKhMWpweFm6jotFAoKyuTm0wr4MaqBm0Pj3yYQRVz rgf+TqnmVdAhMMZB8SXnTKBCO45KYWWziTWrzKnDsY5pIAUphF140j6KQsI3uHlE 1BvBoejp0ENoSj/vaMBb0Kal8k9D/qvJWmMVjX2b29nQ0tnj+mJMRlB4l365Q7p7 jgVFaY4oq8WO578kKuTF+KQ6AvizGPvaCDZFh4s5ozGfUKaYj9wCxKe+x2zRgDK1 SC9lGBfhqmUgID7qHLG3 =8kei -----END PGP SIGNATURE----- --=-vIkqAKTmQv2NBH0MEzQN-- --===============1452918427421707408== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1452918427421707408==--