From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH RESEND 05/12] xen: numa-sched: make space for per-vcpu node-affinity Date: Tue, 5 Nov 2013 17:31:27 +0000 Message-ID: <52792B6F.3050705@eu.citrix.com> References: <20131105142844.30446.78671.stgit@Solace> <20131105143500.30446.9976.stgit@Solace> <5279143702000078000FFB15@nat28.tlf.novell.com> <527908B2.5090208@eu.citrix.com> <52790A93.4020903@eu.citrix.com> <52791B8702000078000FFBC4@nat28.tlf.novell.com> <5279114B.9080405@eu.citrix.com> <52792326.4050206@eu.citrix.com> <527937C102000078000FFD02@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VdkTU-0001Hp-Pd for xen-devel@lists.xenproject.org; Tue, 05 Nov 2013 17:31:32 +0000 In-Reply-To: <527937C102000078000FFD02@nat28.tlf.novell.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: Jan Beulich Cc: MarcusGranado , Justin Weaver , Ian Campbell , Li Yechen , Andrew Cooper , Dario Faggioli , Ian Jackson , Matt Wilson , xen-devel , Daniel De Graaf , KeirFraser , Elena Ufimtseva , JuergenGross List-Id: xen-devel@lists.xenproject.org On 11/05/2013 05:24 PM, Jan Beulich wrote: >>>> On 05.11.13 at 17:56, George Dunlap wrote: >> On 11/05/2013 03:39 PM, George Dunlap wrote: >>> A potential problem with that is the "auto domain numa" thing. In this >>> patch, if the domain numa affinity is not set but vcpu numa affinity is, >>> the domain numa affinity (which will be used to allocate memory for the >>> domain) will be set based on the vcpu numa affinity. That seems like a >>> useful feature (though perhaps it's starting to violate the "policy >>> should be in the tools" principle). If we change this to just "hard >>> affinity" and "soft affinity", we'll lose the natural logical connection >>> there. It might have impacts on how we end up doing vNUMA as well. So >>> I'm a bit torn ATM. >> >> [Coming back after going through the whole series] >> >> This is basically the main architectural question that needs to be >> sorted out with the series: Do we bake in that the "soft affinity" is >> specifically for NUMA-ness, or not? > > I think that it would be beneficial if we could keep the soft > affinity as a more abstract construct than just representing > NUMAness, even if that means that domain node affinity > won't be able to be fully "automated" anymore. But I'm > saying that without having a specific use case in mind. People seem to have found all kinds of fun use cases for the "hard" pinning we have; it's just a handy tool to have around. Allowing an arbitrary "soft" pinning just seems like a similarly handy tool. I'm sure between our users and our downstreams (Suse, Oracle, XenServer, QubesOS, &c &c) someone will find a use for it. :-) -George