Re: [PATCH RESEND 05/12] xen: numa-sched: make space for per-vcpu node-affinity

[George Dunlap <george.dunlap@eu.citrix.com>]

On 11/05/2013 05:24 PM, Jan Beulich wrote:
>>>> On 05.11.13 at 17:56, George Dunlap <george.dunlap@eu.citrix.com> 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