From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Prioritising dom0 vcpus Date: Mon, 3 Jun 2013 18:47:12 +0200 Message-ID: <1370278032.8630.46.camel@Solace> References: <51A8DB53.6010301@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5220375394670487882==" Return-path: In-Reply-To: <51A8DB53.6010301@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Marcus Granado Cc: xen-devel List-Id: xen-devel@lists.xenproject.org --===============5220375394670487882== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-S2uqN6yIfns30gFW9cJp" --=-S2uqN6yIfns30gFW9cJp Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On ven, 2013-05-31 at 18:18 +0100, Marcus Granado wrote: > As an experiment trying to reduce the latency when scheduling dom0=20 > vcpus, I applied the following patch to __runq_insert() to xen 4.2: >=20 > diff -r 8643ca19d356 -r 91b13479c1a2 xen/common/sched_credit.c > --- a/xen/common/sched_credit.c > +++ b/xen/common/sched_credit.c > @@ -205,6 +205,15 @@ > BUG_ON( __vcpu_on_runq(svc) ); > BUG_ON( cpu !=3D svc->vcpu->processor ); >=20 > + /* if svc is a dom0 vcpu, put it always before all the other vcpus= =20 > in the runq, > + * so that dom0 vcpus always have priority > + */ > + if (svc->vcpu->domain->domain_id =3D=3D 0) { > + svc->pri =3D CSCHED_PRI_TS_BOOST; /* make sure no vcpu goes in= =20 > front of this one until this vcpu is scheduled */ > + list_add(&svc->runq_elem, (struct list_head *)runq); > + return; > + } > + > list_for_each( iter, runq ) > { > const struct csched_vcpu * const iter_svc =3D __runq_elem(iter)= ; >=20 Mmm... Are we talking about wakeup latency --which, BTW, is what TS_BOOST is all about, AFAIUI ? In that case, isn't a waking vcpu, whether or not it belongs to Dom0, being boosted already in csched_vcpu_wake()? __runq_insert() is called right after that, so I think it sees the boosting already, without the need of the above. If it's not only wakeup latency issues that you're trying to address, then I'm not sure, but still, __runq_insert() does not look the right place where to place such logic, at least per my personal taste. :-) > However, this patch seems to have had the opposite effect, and I would= =20 > like to understand why. A win7 guest now takes hours to start up, and I= =20 > believe this is due to dom0 taking an order of 10ms to serve each vm i/o= =20 > request, even though the dom0 vcpus and the guest vcpu are in different= =20 > pcpus. >=20 Well, just shooting in the dark, but __runq_insert() is also called in csched_schedule(). Perhaps your modification above interacts badly with the current scheduling logic? Another way of trying to achieve what you seem to be up to, could be to put an "is_it_dom0?" check in csched_vcpu_acct() and, if true, do not clear the boosting. Beware, I'm not saying that it makes sense, or that I like it, it just seems more clean (at least to me) than hijacking __runq_insert(). What do you think? > xenalyze-a.out: http://pastelink.me/getfile.php?key=3D390a25 > xentrace-D-T5.out: http://pastelink.me/getfile.php?key=3Db3d584 >=20 Sorry, can't look at the traces right now... If I find 5 mins for them and spot something weird, I'll let you know. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-S2uqN6yIfns30gFW9cJp 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 v1.4.13 (GNU/Linux) iEYEABECAAYFAlGsyJAACgkQk4XaBE3IOsQQTQCeJISk5/2ZuCMghqxjBxhET0Ar +n8An0XKjlyOA8cSGcY5UZT8XjQwDjWD =mSHk -----END PGP SIGNATURE----- --=-S2uqN6yIfns30gFW9cJp-- --===============5220375394670487882== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5220375394670487882==--