All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] libxl: avoid considering pCPUs outside of the cpupool during NUMA placement
@ 2016-10-21  9:56 Dario Faggioli
  2016-10-21 10:29 ` Wei Liu
  2016-10-21 10:51 ` Juergen Gross
  0 siblings, 2 replies; 6+ messages in thread
From: Dario Faggioli @ 2016-10-21  9:56 UTC (permalink / raw)
  To: xen-devel
  Cc: Juergen Gross, Wei Liu, Anshul Makkar, Ian Jackson, George Dunlap

During NUMA automatic placement, the information
of how many vCPUs can run on what NUMA nodes is used,
in order to spread the load as evenly as possible.

Such information is derived from vCPU hard and soft
affinity, but that is not enough. In fact, affinity
can be set to be a superset of the pCPUs that belongs
to the cpupool in which a domain is but, of course,
the domain will never run on pCPUs outside of its
cpupool.

Take this into account in the placement algorithm.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reported-by: George Dunlap <george.dunlap@citrix.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: George Dunlap <george.dunlap@citrix.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Anshul Makkar <anshul.makkar@citrix.com>
---
Wei, this is bugfix, so I think it should go in 4.8.

Ian, this is bugfix, so I think it is a backporting candidate.

Also, note that this function does not respect the libxl coding style, as far
as error handling is concerned. However, given that I'm asking for it to go in
now and to be backported, I've tried to keep the changes to the minimum.

I'm up for a follow up patch for 4.9 to make the style compliant.

Thanks, Dario
---
 tools/libxl/libxl_numa.c |   25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
index 33289d5..f2a719d 100644
--- a/tools/libxl/libxl_numa.c
+++ b/tools/libxl/libxl_numa.c
@@ -186,9 +186,12 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
 {
     libxl_dominfo *dinfo = NULL;
     libxl_bitmap dom_nodemap, nodes_counted;
+    libxl_cpupoolinfo cpupool_info;
     int nr_doms, nr_cpus;
     int i, j, k;
 
+    libxl_cpupoolinfo_init(&cpupool_info);
+
     dinfo = libxl_list_domain(CTX, &nr_doms);
     if (dinfo == NULL)
         return ERROR_FAIL;
@@ -205,12 +208,18 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
     }
 
     for (i = 0; i < nr_doms; i++) {
-        libxl_vcpuinfo *vinfo;
-        int nr_dom_vcpus;
+        libxl_vcpuinfo *vinfo = NULL;
+        int cpupool, nr_dom_vcpus;
+
+        cpupool = libxl__domain_cpupool(gc, dinfo[i].domid);
+        if (cpupool < 0)
+            goto next;
+        if (libxl_cpupool_info(CTX, &cpupool_info, cpupool))
+            goto next;
 
         vinfo = libxl_list_vcpu(CTX, dinfo[i].domid, &nr_dom_vcpus, &nr_cpus);
         if (vinfo == NULL)
-            continue;
+            goto next;
 
         /* Retrieve the domain's node-affinity map */
         libxl_domain_get_nodeaffinity(CTX, dinfo[i].domid, &dom_nodemap);
@@ -220,6 +229,12 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
              * For each vcpu of each domain, it must have both vcpu-affinity
              * and node-affinity to (a pcpu belonging to) a certain node to
              * cause an increment in the corresponding element of the array.
+             *
+             * Note that we also need to check whether the cpu actually
+             * belongs to the domain's cpupool (the cpupool of the domain
+             * being checked). In fact, it could be that the vcpu has affinity
+             * with cpus in suitable_cpumask, but that are not in its own
+             * cpupool, and we don't want to consider those!
              */
             libxl_bitmap_set_none(&nodes_counted);
             libxl_for_each_set_bit(k, vinfo[j].cpumap) {
@@ -228,6 +243,7 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
                 int node = tinfo[k].node;
 
                 if (libxl_bitmap_test(suitable_cpumap, k) &&
+                    libxl_bitmap_test(&cpupool_info.cpumap, k) &&
                     libxl_bitmap_test(&dom_nodemap, node) &&
                     !libxl_bitmap_test(&nodes_counted, node)) {
                     libxl_bitmap_set(&nodes_counted, node);
@@ -236,7 +252,10 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
             }
         }
 
+ next:
+        libxl_cpupoolinfo_dispose(&cpupool_info);
         libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
+        vinfo = NULL;
     }
 
     libxl_bitmap_dispose(&dom_nodemap);


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

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] libxl: avoid considering pCPUs outside of the cpupool during NUMA placement
  2016-10-21  9:56 [PATCH] libxl: avoid considering pCPUs outside of the cpupool during NUMA placement Dario Faggioli
@ 2016-10-21 10:29 ` Wei Liu
  2016-10-21 10:50   ` Juergen Gross
  2016-10-21 12:52   ` Dario Faggioli
  2016-10-21 10:51 ` Juergen Gross
  1 sibling, 2 replies; 6+ messages in thread
From: Wei Liu @ 2016-10-21 10:29 UTC (permalink / raw)
  To: Dario Faggioli
  Cc: Juergen Gross, Wei Liu, Anshul Makkar, Ian Jackson,
	George Dunlap, xen-devel

On Fri, Oct 21, 2016 at 11:56:14AM +0200, Dario Faggioli wrote:
> During NUMA automatic placement, the information
> of how many vCPUs can run on what NUMA nodes is used,
> in order to spread the load as evenly as possible.
> 
> Such information is derived from vCPU hard and soft
> affinity, but that is not enough. In fact, affinity
> can be set to be a superset of the pCPUs that belongs
> to the cpupool in which a domain is but, of course,
> the domain will never run on pCPUs outside of its
> cpupool.
> 
> Take this into account in the placement algorithm.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Reported-by: George Dunlap <george.dunlap@citrix.com>
> ---
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: George Dunlap <george.dunlap@citrix.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Anshul Makkar <anshul.makkar@citrix.com>
> ---
> Wei, this is bugfix, so I think it should go in 4.8.
> 

Yes. I agree.

> Ian, this is bugfix, so I think it is a backporting candidate.
> 
> Also, note that this function does not respect the libxl coding style, as far
> as error handling is concerned. However, given that I'm asking for it to go in
> now and to be backported, I've tried to keep the changes to the minimum.
> 
> I'm up for a follow up patch for 4.9 to make the style compliant.
> 
> Thanks, Dario
> ---
>  tools/libxl/libxl_numa.c |   25 ++++++++++++++++++++++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
> index 33289d5..f2a719d 100644
> --- a/tools/libxl/libxl_numa.c
> +++ b/tools/libxl/libxl_numa.c
> @@ -186,9 +186,12 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>  {
>      libxl_dominfo *dinfo = NULL;
>      libxl_bitmap dom_nodemap, nodes_counted;
> +    libxl_cpupoolinfo cpupool_info;
>      int nr_doms, nr_cpus;
>      int i, j, k;
>  
> +    libxl_cpupoolinfo_init(&cpupool_info);
> +

Please move this into the loop below, see (*).

>      dinfo = libxl_list_domain(CTX, &nr_doms);
>      if (dinfo == NULL)
>          return ERROR_FAIL;
> @@ -205,12 +208,18 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>      }
>  
>      for (i = 0; i < nr_doms; i++) {
> -        libxl_vcpuinfo *vinfo;
> -        int nr_dom_vcpus;
> +        libxl_vcpuinfo *vinfo = NULL;

This is not necessary because vinfo is written right away.

> +        int cpupool, nr_dom_vcpus;
> +

(*) here.

> +        cpupool = libxl__domain_cpupool(gc, dinfo[i].domid);
> +        if (cpupool < 0)
> +            goto next;
> +        if (libxl_cpupool_info(CTX, &cpupool_info, cpupool))
> +            goto next;
>  
>          vinfo = libxl_list_vcpu(CTX, dinfo[i].domid, &nr_dom_vcpus, &nr_cpus);
>          if (vinfo == NULL)
> -            continue;
> +            goto next;
>  
>          /* Retrieve the domain's node-affinity map */
>          libxl_domain_get_nodeaffinity(CTX, dinfo[i].domid, &dom_nodemap);
> @@ -220,6 +229,12 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>               * For each vcpu of each domain, it must have both vcpu-affinity
>               * and node-affinity to (a pcpu belonging to) a certain node to
>               * cause an increment in the corresponding element of the array.
> +             *
> +             * Note that we also need to check whether the cpu actually
> +             * belongs to the domain's cpupool (the cpupool of the domain
> +             * being checked). In fact, it could be that the vcpu has affinity
> +             * with cpus in suitable_cpumask, but that are not in its own
> +             * cpupool, and we don't want to consider those!
>               */
>              libxl_bitmap_set_none(&nodes_counted);
>              libxl_for_each_set_bit(k, vinfo[j].cpumap) {
> @@ -228,6 +243,7 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>                  int node = tinfo[k].node;
>  
>                  if (libxl_bitmap_test(suitable_cpumap, k) &&
> +                    libxl_bitmap_test(&cpupool_info.cpumap, k) &&
>                      libxl_bitmap_test(&dom_nodemap, node) &&
>                      !libxl_bitmap_test(&nodes_counted, node)) {
>                      libxl_bitmap_set(&nodes_counted, node);
> @@ -236,7 +252,10 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>              }
>          }
>  
> + next:
> +        libxl_cpupoolinfo_dispose(&cpupool_info);
>          libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
> +        vinfo = NULL;

This is not necessary as vinfo is rewritten at the beginning of every
loop.

>      }
>  
>      libxl_bitmap_dispose(&dom_nodemap);
> 

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] libxl: avoid considering pCPUs outside of the cpupool during NUMA placement
  2016-10-21 10:29 ` Wei Liu
@ 2016-10-21 10:50   ` Juergen Gross
  2016-10-21 10:56     ` Wei Liu
  2016-10-21 12:52   ` Dario Faggioli
  1 sibling, 1 reply; 6+ messages in thread
From: Juergen Gross @ 2016-10-21 10:50 UTC (permalink / raw)
  To: Wei Liu, Dario Faggioli
  Cc: xen-devel, Anshul Makkar, Ian Jackson, George Dunlap

On 21/10/16 12:29, Wei Liu wrote:
> On Fri, Oct 21, 2016 at 11:56:14AM +0200, Dario Faggioli wrote:
>> During NUMA automatic placement, the information
>> of how many vCPUs can run on what NUMA nodes is used,
>> in order to spread the load as evenly as possible.
>>
>> Such information is derived from vCPU hard and soft
>> affinity, but that is not enough. In fact, affinity
>> can be set to be a superset of the pCPUs that belongs
>> to the cpupool in which a domain is but, of course,
>> the domain will never run on pCPUs outside of its
>> cpupool.
>>
>> Take this into account in the placement algorithm.
>>
>> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>> Reported-by: George Dunlap <george.dunlap@citrix.com>
>> ---
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Wei Liu <wei.liu2@citrix.com>
>> Cc: George Dunlap <george.dunlap@citrix.com>
>> Cc: Juergen Gross <jgross@suse.com>
>> Cc: Anshul Makkar <anshul.makkar@citrix.com>
>> ---
>> Wei, this is bugfix, so I think it should go in 4.8.
>>
> 
> Yes. I agree.
> 
>> Ian, this is bugfix, so I think it is a backporting candidate.
>>
>> Also, note that this function does not respect the libxl coding style, as far
>> as error handling is concerned. However, given that I'm asking for it to go in
>> now and to be backported, I've tried to keep the changes to the minimum.
>>
>> I'm up for a follow up patch for 4.9 to make the style compliant.
>>
>> Thanks, Dario
>> ---
>>  tools/libxl/libxl_numa.c |   25 ++++++++++++++++++++++---
>>  1 file changed, 22 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
>> index 33289d5..f2a719d 100644
>> --- a/tools/libxl/libxl_numa.c
>> +++ b/tools/libxl/libxl_numa.c
>> @@ -186,9 +186,12 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>>  {
>>      libxl_dominfo *dinfo = NULL;
>>      libxl_bitmap dom_nodemap, nodes_counted;
>> +    libxl_cpupoolinfo cpupool_info;
>>      int nr_doms, nr_cpus;
>>      int i, j, k;
>>  
>> +    libxl_cpupoolinfo_init(&cpupool_info);
>> +
> 
> Please move this into the loop below, see (*).

Why? libxl_cpupoolinfo_dispose() will clear cpupool_info.

> 
>>      dinfo = libxl_list_domain(CTX, &nr_doms);
>>      if (dinfo == NULL)
>>          return ERROR_FAIL;
>> @@ -205,12 +208,18 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>>      }
>>  
>>      for (i = 0; i < nr_doms; i++) {
>> -        libxl_vcpuinfo *vinfo;
>> -        int nr_dom_vcpus;
>> +        libxl_vcpuinfo *vinfo = NULL;
> 
> This is not necessary because vinfo is written right away.

No, the first "goto next" is before vinfo is being written.

> 
>> +        int cpupool, nr_dom_vcpus;
>> +
> 
> (*) here.
> 
>> +        cpupool = libxl__domain_cpupool(gc, dinfo[i].domid);
>> +        if (cpupool < 0)
>> +            goto next;
>> +        if (libxl_cpupool_info(CTX, &cpupool_info, cpupool))
>> +            goto next;
>>  
>>          vinfo = libxl_list_vcpu(CTX, dinfo[i].domid, &nr_dom_vcpus, &nr_cpus);
>>          if (vinfo == NULL)
>> -            continue;
>> +            goto next;
>>  
>>          /* Retrieve the domain's node-affinity map */
>>          libxl_domain_get_nodeaffinity(CTX, dinfo[i].domid, &dom_nodemap);
>> @@ -220,6 +229,12 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>>               * For each vcpu of each domain, it must have both vcpu-affinity
>>               * and node-affinity to (a pcpu belonging to) a certain node to
>>               * cause an increment in the corresponding element of the array.
>> +             *
>> +             * Note that we also need to check whether the cpu actually
>> +             * belongs to the domain's cpupool (the cpupool of the domain
>> +             * being checked). In fact, it could be that the vcpu has affinity
>> +             * with cpus in suitable_cpumask, but that are not in its own
>> +             * cpupool, and we don't want to consider those!
>>               */
>>              libxl_bitmap_set_none(&nodes_counted);
>>              libxl_for_each_set_bit(k, vinfo[j].cpumap) {
>> @@ -228,6 +243,7 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>>                  int node = tinfo[k].node;
>>  
>>                  if (libxl_bitmap_test(suitable_cpumap, k) &&
>> +                    libxl_bitmap_test(&cpupool_info.cpumap, k) &&
>>                      libxl_bitmap_test(&dom_nodemap, node) &&
>>                      !libxl_bitmap_test(&nodes_counted, node)) {
>>                      libxl_bitmap_set(&nodes_counted, node);
>> @@ -236,7 +252,10 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>>              }
>>          }
>>  
>> + next:
>> +        libxl_cpupoolinfo_dispose(&cpupool_info);
>>          libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
>> +        vinfo = NULL;
> 
> This is not necessary as vinfo is rewritten at the beginning of every
> loop.
> 
>>      }
>>  
>>      libxl_bitmap_dispose(&dom_nodemap);
>>


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] libxl: avoid considering pCPUs outside of the cpupool during NUMA placement
  2016-10-21  9:56 [PATCH] libxl: avoid considering pCPUs outside of the cpupool during NUMA placement Dario Faggioli
  2016-10-21 10:29 ` Wei Liu
@ 2016-10-21 10:51 ` Juergen Gross
  1 sibling, 0 replies; 6+ messages in thread
From: Juergen Gross @ 2016-10-21 10:51 UTC (permalink / raw)
  To: Dario Faggioli, xen-devel
  Cc: Wei Liu, Anshul Makkar, Ian Jackson, George Dunlap

On 21/10/16 11:56, Dario Faggioli wrote:
> During NUMA automatic placement, the information
> of how many vCPUs can run on what NUMA nodes is used,
> in order to spread the load as evenly as possible.
> 
> Such information is derived from vCPU hard and soft
> affinity, but that is not enough. In fact, affinity
> can be set to be a superset of the pCPUs that belongs
> to the cpupool in which a domain is but, of course,
> the domain will never run on pCPUs outside of its
> cpupool.
> 
> Take this into account in the placement algorithm.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Reported-by: George Dunlap <george.dunlap@citrix.com>

Reviewed-by: Juergen Gross <jgross@suse.com>

> ---
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: George Dunlap <george.dunlap@citrix.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Anshul Makkar <anshul.makkar@citrix.com>
> ---
> Wei, this is bugfix, so I think it should go in 4.8.
> 
> Ian, this is bugfix, so I think it is a backporting candidate.
> 
> Also, note that this function does not respect the libxl coding style, as far
> as error handling is concerned. However, given that I'm asking for it to go in
> now and to be backported, I've tried to keep the changes to the minimum.
> 
> I'm up for a follow up patch for 4.9 to make the style compliant.
> 
> Thanks, Dario
> ---
>  tools/libxl/libxl_numa.c |   25 ++++++++++++++++++++++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
> index 33289d5..f2a719d 100644
> --- a/tools/libxl/libxl_numa.c
> +++ b/tools/libxl/libxl_numa.c
> @@ -186,9 +186,12 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>  {
>      libxl_dominfo *dinfo = NULL;
>      libxl_bitmap dom_nodemap, nodes_counted;
> +    libxl_cpupoolinfo cpupool_info;
>      int nr_doms, nr_cpus;
>      int i, j, k;
>  
> +    libxl_cpupoolinfo_init(&cpupool_info);
> +
>      dinfo = libxl_list_domain(CTX, &nr_doms);
>      if (dinfo == NULL)
>          return ERROR_FAIL;
> @@ -205,12 +208,18 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>      }
>  
>      for (i = 0; i < nr_doms; i++) {
> -        libxl_vcpuinfo *vinfo;
> -        int nr_dom_vcpus;
> +        libxl_vcpuinfo *vinfo = NULL;
> +        int cpupool, nr_dom_vcpus;
> +
> +        cpupool = libxl__domain_cpupool(gc, dinfo[i].domid);
> +        if (cpupool < 0)
> +            goto next;
> +        if (libxl_cpupool_info(CTX, &cpupool_info, cpupool))
> +            goto next;
>  
>          vinfo = libxl_list_vcpu(CTX, dinfo[i].domid, &nr_dom_vcpus, &nr_cpus);
>          if (vinfo == NULL)
> -            continue;
> +            goto next;
>  
>          /* Retrieve the domain's node-affinity map */
>          libxl_domain_get_nodeaffinity(CTX, dinfo[i].domid, &dom_nodemap);
> @@ -220,6 +229,12 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>               * For each vcpu of each domain, it must have both vcpu-affinity
>               * and node-affinity to (a pcpu belonging to) a certain node to
>               * cause an increment in the corresponding element of the array.
> +             *
> +             * Note that we also need to check whether the cpu actually
> +             * belongs to the domain's cpupool (the cpupool of the domain
> +             * being checked). In fact, it could be that the vcpu has affinity
> +             * with cpus in suitable_cpumask, but that are not in its own
> +             * cpupool, and we don't want to consider those!
>               */
>              libxl_bitmap_set_none(&nodes_counted);
>              libxl_for_each_set_bit(k, vinfo[j].cpumap) {
> @@ -228,6 +243,7 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>                  int node = tinfo[k].node;
>  
>                  if (libxl_bitmap_test(suitable_cpumap, k) &&
> +                    libxl_bitmap_test(&cpupool_info.cpumap, k) &&
>                      libxl_bitmap_test(&dom_nodemap, node) &&
>                      !libxl_bitmap_test(&nodes_counted, node)) {
>                      libxl_bitmap_set(&nodes_counted, node);
> @@ -236,7 +252,10 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
>              }
>          }
>  
> + next:
> +        libxl_cpupoolinfo_dispose(&cpupool_info);
>          libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
> +        vinfo = NULL;
>      }
>  
>      libxl_bitmap_dispose(&dom_nodemap);
> 
> 


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] libxl: avoid considering pCPUs outside of the cpupool during NUMA placement
  2016-10-21 10:50   ` Juergen Gross
@ 2016-10-21 10:56     ` Wei Liu
  0 siblings, 0 replies; 6+ messages in thread
From: Wei Liu @ 2016-10-21 10:56 UTC (permalink / raw)
  To: Juergen Gross
  Cc: Wei Liu, Dario Faggioli, Ian Jackson, George Dunlap, xen-devel,
	Anshul Makkar

On Fri, Oct 21, 2016 at 12:50:58PM +0200, Juergen Gross wrote:
> On 21/10/16 12:29, Wei Liu wrote:
> > On Fri, Oct 21, 2016 at 11:56:14AM +0200, Dario Faggioli wrote:
> >> During NUMA automatic placement, the information
> >> of how many vCPUs can run on what NUMA nodes is used,
> >> in order to spread the load as evenly as possible.
> >>
> >> Such information is derived from vCPU hard and soft
> >> affinity, but that is not enough. In fact, affinity
> >> can be set to be a superset of the pCPUs that belongs
> >> to the cpupool in which a domain is but, of course,
> >> the domain will never run on pCPUs outside of its
> >> cpupool.
> >>
> >> Take this into account in the placement algorithm.
> >>
> >> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> >> Reported-by: George Dunlap <george.dunlap@citrix.com>
> >> ---
> >> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >> Cc: Wei Liu <wei.liu2@citrix.com>
> >> Cc: George Dunlap <george.dunlap@citrix.com>
> >> Cc: Juergen Gross <jgross@suse.com>
> >> Cc: Anshul Makkar <anshul.makkar@citrix.com>
> >> ---
> >> Wei, this is bugfix, so I think it should go in 4.8.
> >>
> > 
> > Yes. I agree.
> > 
> >> Ian, this is bugfix, so I think it is a backporting candidate.
> >>
> >> Also, note that this function does not respect the libxl coding style, as far
> >> as error handling is concerned. However, given that I'm asking for it to go in
> >> now and to be backported, I've tried to keep the changes to the minimum.
> >>
> >> I'm up for a follow up patch for 4.9 to make the style compliant.
> >>
> >> Thanks, Dario
> >> ---
> >>  tools/libxl/libxl_numa.c |   25 ++++++++++++++++++++++---
> >>  1 file changed, 22 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
> >> index 33289d5..f2a719d 100644
> >> --- a/tools/libxl/libxl_numa.c
> >> +++ b/tools/libxl/libxl_numa.c
> >> @@ -186,9 +186,12 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
> >>  {
> >>      libxl_dominfo *dinfo = NULL;
> >>      libxl_bitmap dom_nodemap, nodes_counted;
> >> +    libxl_cpupoolinfo cpupool_info;
> >>      int nr_doms, nr_cpus;
> >>      int i, j, k;
> >>  
> >> +    libxl_cpupoolinfo_init(&cpupool_info);
> >> +
> > 
> > Please move this into the loop below, see (*).
> 
> Why? libxl_cpupoolinfo_dispose() will clear cpupool_info.
> 

One _init should pair with one _dipose.

Even _dispose is idempotent at the moment, it might not be so in the
future.

> > 
> >>      dinfo = libxl_list_domain(CTX, &nr_doms);
> >>      if (dinfo == NULL)
> >>          return ERROR_FAIL;
> >> @@ -205,12 +208,18 @@ static int nr_vcpus_on_nodes(libxl__gc *gc, libxl_cputopology *tinfo,
> >>      }
> >>  
> >>      for (i = 0; i < nr_doms; i++) {
> >> -        libxl_vcpuinfo *vinfo;
> >> -        int nr_dom_vcpus;
> >> +        libxl_vcpuinfo *vinfo = NULL;
> > 
> > This is not necessary because vinfo is written right away.
> 
> No, the first "goto next" is before vinfo is being written.
> 

Yes, this is necessary. Thanks for catching this.

Wei.

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] libxl: avoid considering pCPUs outside of the cpupool during NUMA placement
  2016-10-21 10:29 ` Wei Liu
  2016-10-21 10:50   ` Juergen Gross
@ 2016-10-21 12:52   ` Dario Faggioli
  1 sibling, 0 replies; 6+ messages in thread
From: Dario Faggioli @ 2016-10-21 12:52 UTC (permalink / raw)
  To: Wei Liu
  Cc: Juergen Gross, xen-devel, Anshul Makkar, Ian Jackson, George Dunlap


[-- Attachment #1.1: Type: text/plain, Size: 2711 bytes --]

On Fri, 2016-10-21 at 11:29 +0100, Wei Liu wrote:
> On Fri, Oct 21, 2016 at 11:56:14AM +0200, Dario Faggioli wrote:
> > diff --git a/tools/libxl/libxl_numa.c b/tools/libxl/libxl_numa.c
> > index 33289d5..f2a719d 100644
> > --- a/tools/libxl/libxl_numa.c
> > +++ b/tools/libxl/libxl_numa.c
> > @@ -186,9 +186,12 @@ static int nr_vcpus_on_nodes(libxl__gc *gc,
> > libxl_cputopology *tinfo,
> >  {
> >      libxl_dominfo *dinfo = NULL;
> >      libxl_bitmap dom_nodemap, nodes_counted;
> > +    libxl_cpupoolinfo cpupool_info;
> >      int nr_doms, nr_cpus;
> >      int i, j, k;
> >  
> > +    libxl_cpupoolinfo_init(&cpupool_info);
> > +
> 
> Please move this into the loop below, see (*).
> 
Seems unnecessary, but I certainly can do that. I guess it makes the
code less dependent from the actual implementation
of libxl_cpupoolinfo_dispose(), which is probably a good thing.

> > 
> >      dinfo = libxl_list_domain(CTX, &nr_doms);
> >      if (dinfo == NULL)
> >          return ERROR_FAIL;
> > @@ -205,12 +208,18 @@ static int nr_vcpus_on_nodes(libxl__gc *gc,
> > libxl_cputopology *tinfo,
> >      }
> >  
> >      for (i = 0; i < nr_doms; i++) {
> > -        libxl_vcpuinfo *vinfo;
> > -        int nr_dom_vcpus;
> > +        libxl_vcpuinfo *vinfo = NULL;
> 
> This is not necessary because vinfo is written right away.
> 
Is it? It was before this patch, but with it, if this [*] fails...

> > 
> > +        int cpupool, nr_dom_vcpus;
> > +
> > +        cpupool = libxl__domain_cpupool(gc, dinfo[i].domid);
> > +        if (cpupool < 0)

[*]

> > +            goto next;

... we go to next which does libxl_vcpuinfo_list_free() on a non-
initialised pointer

> > @@ -236,7 +252,10 @@ static int nr_vcpus_on_nodes(libxl__gc *gc,
> > libxl_cputopology *tinfo,
> >              }
> >          }
> >  
> > + next:
> > +        libxl_cpupoolinfo_dispose(&cpupool_info);
> >          libxl_vcpuinfo_list_free(vinfo, nr_dom_vcpus);
> > +        vinfo = NULL;
> 
> This is not necessary as vinfo is rewritten at the beginning of every
> loop.

Actually, I do agree that this is not necessary, iff I keep the
assignment there, at the beginning of the loop... or am I missing
something?

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-10-21 12:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-21  9:56 [PATCH] libxl: avoid considering pCPUs outside of the cpupool during NUMA placement Dario Faggioli
2016-10-21 10:29 ` Wei Liu
2016-10-21 10:50   ` Juergen Gross
2016-10-21 10:56     ` Wei Liu
2016-10-21 12:52   ` Dario Faggioli
2016-10-21 10:51 ` Juergen Gross

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.