From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH] Xen sched: Fix multiple runqueues in credit2 Date: Thu, 06 Feb 2014 14:54:00 +0100 Message-ID: <52F393F8.8010206@ts.fujitsu.com> References: <1391677118-3071-1-git-send-email-jtweaver@hawaii.edu> <52F35238.90806@ts.fujitsu.com> <1391694283.9917.8.camel@Solace> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1391694283.9917.8.camel@Solace> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli 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 On 06.02.2014 14:44, Dario Faggioli wrote: > 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 >> >> You should check whether cpu and CPU0 are in the same cpupool. >> >> BTW: CPU0 is allowed to be moved to another cpupool, too. >> > 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? Now it will construct one runqueue per cpupool. There is one sched_private structure per cpupool! I'm not sure what will happen with the change proposed by Justin in case of multiple credit2 cpupools... Juergen -- Juergen Gross Principal Developer Operating Systems PBG PDG ES&S SWE OS6 Telephone: +49 (0) 89 62060 2932 Fujitsu e-mail: juergen.gross@ts.fujitsu.com Mies-van-der-Rohe-Str. 8 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html