From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] xen: avoid updating node affinity twice when removing a CPU from a cpupool Date: Thu, 12 Mar 2015 14:52:46 +0000 Message-ID: <5501A83E.6090303@eu.citrix.com> References: <20150309164901.11859.95044.stgit@Solace.station> <550058BB.7000102@eu.citrix.com> <1426089874.21405.10.camel@citrix.com> <1426167922.7023.21.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1426167922.7023.21.camel@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: Dario Faggioli , George Dunlap Cc: "JGross@suse.com" , "keir.xen@gmail.com" , "jtweaver@hawaii.edu" , "JBeulich@suse.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 03/12/2015 01:45 PM, Dario Faggioli wrote: > On Wed, 2015-03-11 at 16:04 +0000, Dario Faggioli wrote: >> On Wed, 2015-03-11 at 15:01 +0000, George Dunlap wrote: > >>> It looks like domain_update_node_affinity() is already called for each >>> domain in the cpupool in cpu_disable_scheduler(). It doesn't look like >>> there should be a need to call it twice. Can we just remove the call to >>> domain_update_node_affinity() in cpupool_unassign_cpu() and not add it back? >>> >> Mmm.. true, actually. >> >> I'll send a patch to that effect. >> > Patch below, and attached. However, I think the correct thing to do > would be to just revert 93be8285 "update domU's node-affinity on the > cpupool_unassign_cpu() path", wouldn't it? Funny you should mention that... one of the things I was thinking of suggesting was trying to move the domain_update_node_affinity() out of cpupool.c and into schedule.c, somewhere on the path that brings up a cpu or assigns it to a pool, specifically so that the lack of symmetry didn't trip anybody up. But at a quick glance I couldn't find a likely candidate. Now that I find out it already *has* tripped someone up, I think we had definitely better do something about it. :-) Let me take a look and see what seems sensible... -George