From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v2 12/16] libxl: get and set soft affinity Date: Fri, 15 Nov 2013 12:02:50 +0000 Message-ID: <52860D6A.30901@eu.citrix.com> References: <20131113190852.18086.5437.stgit@Solace> <20131113191250.18086.1220.stgit@Solace> <21124.59400.960708.501641@mariner.uk.xensource.com> <5284F272.5070302@eu.citrix.com> <21124.63867.762364.416870@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21124.63867.762364.416870@mariner.uk.xensource.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: Ian Jackson Cc: Marcus Granado , Keir Fraser , Ian Campbell , Li Yechen , Andrew Cooper , Dario Faggioli , xen-devel@lists.xen.org, Jan Beulich , Justin Weaver , Matt Wilson , Juergen Gross , Elena Ufimtseva List-Id: xen-devel@lists.xenproject.org On 14/11/13 16:25, Ian Jackson wrote: > George Dunlap writes ("Re: [PATCH v2 12/16] libxl: get and set soft affinity"): >> On 14/11/13 15:11, Ian Jackson wrote: >>> So perhaps we should have a singe function that can change the >>> cpupool, hard affinity, and soft affinity, all at once ? >> I think this is probably a good idea. Would it make sense to basically >> have libxl_[gs]et_vcpuaffinity2(), which takes a parameter that can >> specify that the mask is for either hard, soft, or both? > No, it needs to take at least two separate parameters for the hard and > soft masks, because the toolstack might want to set the hard affinity > and soft affinity to different values, without having to think > carefully about ordering these calls to avoid generating spurious > warnings and incompatible arrangements. > > I think this probably applies to cpupool changes too. So perhaps the > function should look a bit like setresuid or something: it should take > an optional new cpupool (is there a sentinel value that can be used to > mean "no change"?), an optional new soft mask, and an optional new > hard mask. > >>> What if the application makes a call to change the cpupool, without >>> touching the affinities ? Should the affinities be reset >>> automatically ? >> I think whatever happens for hard affinities right now should be carried on. > Maybe it is a bug that it doesn't do anything. I think it depends how > we expect people to use this. If a caller sets the hard affinities > and then changes the cpupool, are they supposed to always then set the > hard affinities again to a new suitable value ? Well in fact, as far as I can tell, it *does* do something. When moving a vcpu to a new pool, it unconditionally calls cpumask_setall(v->cpu_affinity) for each vcpu, which will effectively erase the hard affinity. (xen/common/schedule.c:sched_move_domain()). And, when unplugging cpus, if it unplugs the last cpu a vcpu can run on, it also resets the affinity to "all". -George