From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] Xen sched: Fix multiple runqueues in credit2 Date: Thu, 6 Feb 2014 14:44:43 +0100 Message-ID: <1391694283.9917.8.camel@Solace> References: <1391677118-3071-1-git-send-email-jtweaver@hawaii.edu> <52F35238.90806@ts.fujitsu.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7483079689061036635==" Return-path: In-Reply-To: <52F35238.90806@ts.fujitsu.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: Juergen Gross Cc: Marcus.Granado@eu.citrix.com, Justin Weaver , george.dunlap@eu.citrix.com, esb@ics.hawaii.edu, xen-devel@lists.xen.org, henric@hawaii.edu List-Id: xen-devel@lists.xenproject.org --===============7483079689061036635== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0uFMVA0Ym1wNlcV1oe0y" --=-0uFMVA0Ym1wNlcV1oe0y Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On gio, 2014-02-06 at 10:13 +0100, Juergen Gross wrote: > On 06.02.2014 09:58, Justin Weaver wrote: > > This patch attempts to address the issue of the Xen Credit 2 > > Scheduler only creating one vCPU run queue on multiple physical > > processor systems. It should be creating one run queue per > > physical processor. > > > > CPU 0 does not get a starting callback, so it is hard coded to run > > queue 0. At the time this happens, socket information is not > > available for CPU 0. > > > > Socket information is available for each individual CPU when each > > gets the STARTING callback (I believe socket information is also > > available for CPU 0 by that time). This patch adds the following > > algorithm... > > > > IF cpu is on the same socket as CPU 0, add it to run queue 0 >=20 > You should check whether cpu and CPU0 are in the same cpupool. >=20 > BTW: CPU0 is allowed to be moved to another cpupool, too. >=20 Good points. However, the code, as it is now, does not look to care much about cpupools while constructing this 'one runqueue per socket' thing, does it? I mean, what happens, right now, if, either after or credit2 builds up the runqueues --say one per socket-- two pCPUs from the same socket are in different cpupools? It looks to me that things are considered orthogonal while, as you say, tthy may not be... I guess I'll try that ASAP and let you know... My point being that, Justing is trying to fix a bug in credit2, which says it constructs one runqueue per socket, while it ends up with only one runqueue at all. If there is another bug, or buggy behavior, wrt how this interacts with cpupools, although we should fix that too, that's pre-existent and needs addressing in a dedicated patch (series), isn't it? Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-0uFMVA0Ym1wNlcV1oe0y 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 iEYEABECAAYFAlLzkcsACgkQk4XaBE3IOsQNjgCdHzgTeXM/9cjFB8xfU7raBTtC rloAoJUiQBslKJDU/WCdn/w4wu+3LF38 =wr9Y -----END PGP SIGNATURE----- --=-0uFMVA0Ym1wNlcV1oe0y-- --===============7483079689061036635== 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 --===============7483079689061036635==--