Re: [Xen-devel] [PATCH 1/5] x86: allow specifying the NUMA nodes Dom0 should run on

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.02.15 at 18:14, <dario.faggioli@xxxxxxxxxx> wrote:
> On Thu, 2015-02-26 at 13:52 +0000, Jan Beulich wrote:
>> +### dom0\_nodes
>> +
>> +> `= <integer>[,...]`
>> +
>> +Specify the NUMA nodes to place Dom0 on. Defaults for vCPU-s created
>> +and memory assigned to Dom0 will be adjusted to match the node
>> +restrictions set up here. Note that the values to be specified here are
>> +ACPI PXM ones, not Xen internal node numbers.
>> +
> Why use PXM ids? It might be me being much more used to work with NUMA
> node ids, but wouldn't the other way round be more consistent (almost
> everything the user interacts with after boot speak node ids) and easier
> for the user to figure things out (e.g., with tools like numactl on
> baremetal)?

This way behavior doesn't change if internally in the hypervisor we
need to change the mapping from PXMs to node IDs.

>> +static struct vcpu *__init setup_vcpu(struct domain *d, unsigned int 
>> vcpu_id,
>> +                                      unsigned int cpu)
>> +{
>> +    struct vcpu *v = alloc_vcpu(d, vcpu_id, cpu);
>> +
>> +    if ( v )
>> +    {
>> +        if ( !d->is_pinned )
>> +            cpumask_copy(v->cpu_hard_affinity, &dom0_cpus);
>> +        cpumask_copy(v->cpu_soft_affinity, &dom0_cpus);
>> +    }
>> +
> About this, for DomUs, now that we have soft affinity available, what we
> do is set only soft affinity to match the NUMA placement. I think I see
> and agree why we want to be 'more strict' in Dom0, but I felt like it
> was worth to point out the difference in behaviour (should it be
> documented somewhere?).

I'm simply adjusting what sched_init_vcpu() did, which is alter
hard affinity conditionally on is_pinned and soft affinity
unconditionally.

> BTW, mostly out of curiosity, I've had a few strange issues/conflicts in
> applying this on top of staging, in order to test it... Was it me doing
> something very stupid, or was this based on something different?

Apart from the one patch named in the cover letter there shouldn't
be any other dependencies. Without you naming the issues you
encountered, I can't tell.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel