xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Dario Faggioli <dario.faggioli@citrix.com>,
	xen-devel@lists.xenproject.org
Cc: Wei Liu <wei.liu2@citrix.com>,
	Anshul Makkar <anshul.makkar@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	George Dunlap <george.dunlap@citrix.com>
Subject: Re: [PATCH] libxl: avoid considering pCPUs outside of the cpupool during NUMA placement
Date: Fri, 21 Oct 2016 12:51:22 +0200	[thread overview]
Message-ID: <c747f7d2-edcb-5663-1113-24976f94e550@suse.com> (raw)
In-Reply-To: <147704377421.10420.14327289650457148893.stgit@Solace.fritz.box>

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

      parent reply	other threads:[~2016-10-21 10:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c747f7d2-edcb-5663-1113-24976f94e550@suse.com \
    --to=jgross@suse.com \
    --cc=anshul.makkar@citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).