From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v3 11/14] libxl: get and set soft affinity Date: Wed, 20 Nov 2013 14:09:48 +0000 Message-ID: <528CC2AC.9040602@eu.citrix.com> References: <20131118175544.31002.79574.stgit@Solace> <20131118181813.31002.61195.stgit@Solace> <528B86A0.5000905@eu.citrix.com> <1384877346.19880.121.camel@Abyss> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1384877346.19880.121.camel@Abyss> 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 , Keir Fraser , Ian Campbell , Li Yechen , Andrew Cooper , Juergen Gross , Ian Jackson , xen-devel@lists.xen.org, Jan Beulich , Justin Weaver , Matt Wilson , Elena Ufimtseva List-Id: xen-devel@lists.xenproject.org On 19/11/13 16:09, Dario Faggioli wrote: > On mar, 2013-11-19 at 15:41 +0000, George Dunlap wrote: >> On 11/18/2013 06:18 PM, Dario Faggioli wrote: >>> Make space for two new cpumap-s, one in vcpu_info (for getting >>> soft affinity) and build_info (for setting it). Provide two >>> new API calls: >>> >>> * libxl_set_vcpuaffinity2, taking a cpumap and setting either >>> hard, soft or both affinity to it, depending on 'flags'; >>> * libxl_set_vcpuaffinity3, taking two cpumap, one for hard >>> and one for soft affinity. >>> >>> The bheavior of the existing libxl_set_vcpuaffinity is left >>> unchanged, i.e., it only set hard affinity. >>> >>> Getting soft affinity happens indirectly, via `xl vcpu-list' >>> (as it is already for hard affinity). >>> >>> The new calls include logic to check whether the affinity which >>> will be used by Xen to schedule the vCPU(s) does actually match >>> with the cpumap provided. In fact, we want to allow every possible >>> combination of hard and soft affinities to be set, but we warn >>> the user upon particularly weird combinations (e.g., hard and >>> soft being disjoint sets of pCPUs). >>> >>> Also, this is the first change breaking the libxl ABI, so it >>> bumps the MAJOR. >>> >>> Signed-off-by: Dario Faggioli >> The interface is fine with me (I would probably just have 2 and not 3, >> but I'm OK with both). Just a few minor comments: >> > the '3' variant (tries to) accomplish what IanJ explicitly asked: having > a way to set both hard and soft affinity at the same time, and each with > its own value, and only checking for consistency at the very end. > > I also wasn't sure whether that would have been actually useful but, I > have to admit, it turned out it is, as it can be seen in the following > patches, when the interface is used to (re)implement both the existing > and the new xl commands and command variants. > > Let's see what IanJ thinks, I guess. :-) BTW, I wasn't complaining -- I know IanJ wanted it the second way; I was just re-registering my preference. :-) -George