From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: dependences for backporting to 4.6 [was: Re: [PATCH 2/3] xen: Have schedulers revise initial placement] Date: Fri, 12 Aug 2016 03:59:48 +0200 Message-ID: <1470967188.6250.48.camel@citrix.com> References: <1468605722-24239-1-git-send-email-george.dunlap@citrix.com> <1468605722-24239-2-git-send-email-george.dunlap@citrix.com> <579F434B0200007800101346@prv-mh.provo.novell.com> <1470054737.3311.0.camel@citrix.com> <57A4AFA70200007800103367@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5850234752117427089==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bY1lN-00060v-NU for xen-devel@lists.xenproject.org; Fri, 12 Aug 2016 01:59:57 +0000 In-Reply-To: <57A4AFA70200007800103367@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich , George Dunlap Cc: xen-devel@lists.xenproject.org, Anshul Makkar , MengXu List-Id: xen-devel@lists.xenproject.org --===============5850234752117427089== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-dgdjvynjHPwxLS6fhehm" --=-dgdjvynjHPwxLS6fhehm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2016-08-05 at 07:24 -0600, Jan Beulich wrote: > I'd really like to have those backported, but I have to ask one > of you to identify which prereq-s are needed on 4.6 and 4.5 > (I'll revert them from 4.5 right away, but I'll wait for an osstest > flight to confirm the same issue exists on 4.6). > So, for 4.6, I think the only prerequisite would be this: 6b53bb4ab3c9bd5eccde88a5175cf72589ba6d52 "sched: better handle (not) inserting idle vCPUs in runqueues" That, however, does not apply cleanly. The important part of it is the last hunk: diff --git a/xen/common/schedule.c b/xen/common/schedule.c index 92057eb..c195129 100644 --- a/xen/common/schedule.c +++ b/xen/common/schedule.c @@ -240,20 +240,22 @@ int sched_init_vcpu(struct vcpu *v, unsigned int proc= essor) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0init_timer(&v->poll_timer, poll_timer_fn, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0v, v->processor); =C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0/* Idle VCPUs are scheduled immediately. */ +=C2=A0=C2=A0=C2=A0=C2=A0v->sched_priv =3D SCHED_OP(DOM2OP(d), alloc_vdata,= v, d->sched_priv); +=C2=A0=C2=A0=C2=A0=C2=A0if ( v->sched_priv =3D=3D NULL ) +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return 1; + +=C2=A0=C2=A0=C2=A0=C2=A0TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, = v->vcpu_id); + +=C2=A0=C2=A0=C2=A0=C2=A0/* Idle VCPUs are scheduled immediately, so don't = put them in runqueue. */ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if ( is_idle_domain(d) ) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0per_cpu(schedule_data= , v->processor).curr =3D v; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0v->is_running =3D 1; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0} - -=C2=A0=C2=A0=C2=A0=C2=A0TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, = v->vcpu_id); - -=C2=A0=C2=A0=C2=A0=C2=A0v->sched_priv =3D SCHED_OP(DOM2OP(d), alloc_vdata,= v, d->sched_priv); -=C2=A0=C2=A0=C2=A0=C2=A0if ( v->sched_priv =3D=3D NULL ) -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return 1; - -=C2=A0=C2=A0=C2=A0=C2=A0SCHED_OP(DOM2OP(d), insert_vcpu, v); +=C2=A0=C2=A0=C2=A0=C2=A0else +=C2=A0=C2=A0=C2=A0=C2=A0{ +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0SCHED_OP(DOM2OP(d), insert= _vcpu, v); +=C2=A0=C2=A0=C2=A0=C2=A0} =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return 0; =C2=A0} With this only applied, things works for me. The hunk is actually the core of the patch, the only real functionality change. The other hunks are refactoring and cleanups (made possible by it). So, I'm not sure whether the best route here is: =C2=A0- fully backport 6b53bb4ab3c9b; =C2=A0- backport only the last hunk of 6b53bb4ab3c9b as its own patch; =C2=A0- fold the last hunk of 6b53bb4ab3c9b in the backport of George's=C2= =A0 =C2=A0 =C2=A0patch (I mean, what was=C2=A083dff3992a89 in staging-4.6); Thoughts? Note that the issue Andrew is reporting (on 4.7) is, IMO, unrelated to the hunk above, and may well affect staging as well and (if that's the case) should be fixed there, and the fix backported, I think. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-dgdjvynjHPwxLS6fhehm 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 iQIcBAABCAAGBQJXrS2UAAoJEBZCeImluHPu8RkP/RzRAHWF5a6X9mdbrUyiYpP6 uotGGm8oLevlLkrVdNg3Vygh/SArz62HBAYmcg5nrz8sYgD2ASpQDIXXTFidsC4g IJJqI/9DCi0R9+oLPX+ISsnPZr9uA5p7KvqfI5tw8q2J4WIEvtgjAUig/rd4PBjE RQnxewoav4HOhEnBavIZJrDYKxCnvOcB8tZ+V7Uyp0hl9AjooVcdGJdDrr8v8CcO 6f/C6n2tQp7xrXbGuAK+/mA8flEwD6A3tIafJ/VprLFFCGzbuefJe0sk2+Wiq+40 EiWEwtidcLb2kH8PFtUEAEaM/c59/+gY87YVA/q6XQrk0+gj7qWuJchGNIayyhUy k9A9jonXo5SB5ZtxfhvFS3dgIH5cW1KDAeZPYmF6Ep27kKLCgH4Q4Iy1g3eqjTBV w89vTuhKgPcENGaSio4gFb0KTBrZjclynw4iKfH0vnfbfAnzBJLCVoBVNRYoL2LN sBT/Y810VeDR9yfLszqI2HSnFYvyyFvzEMy+lRP8i+NuQCT3IPKJ3A+eQi8H8zzt XAaUdHqhSUbkn6I8DmvEaf4IpxHTgVqg3nYmlyfNJl4A7dCkZkWLe3FtdToA3ihv LdZvuVhHFbg/BUsXd9HwbrOjNZ3IQESgZ6YCtVy5C4HOAfNpA3JsAoBkd1XRihHe kVPRJs8QgsbiuzPpOYUl =5QRU -----END PGP SIGNATURE----- --=-dgdjvynjHPwxLS6fhehm-- --===============5850234752117427089== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5850234752117427089==--