From: Dario Faggioli <dario.faggioli@citrix.com>
To: xen-devel@lists.xen.org
Cc: keir@xen.org, Ian.Campbell@citrix.com, Andrew.Cooper3@citrix.com,
George.Dunlap@citrix.com, JBeulich@suse.com,
Ian.Jackson@citrix.com
Subject: [v7 PATCH 10/10] libxl: automatic NUMA placement affects soft affinity
Date: Tue, 10 Jun 2014 02:45:45 +0200 [thread overview]
Message-ID: <20140610004545.16660.14597.stgit@Solace> (raw)
In-Reply-To: <20140610002959.16660.44334.stgit@Solace>
vCPU soft affinity and NUMA-aware scheduling does not have
to be related. However, soft affinity is how NUMA-aware
scheduling is actually implemented, and therefore, by default,
the results of automatic NUMA placement (at VM creation time)
are also used to set the soft affinity of all the vCPUs of
the domain.
Of course, this only happens if automatic NUMA placement is
enabled and actually takes place (for instance, if the user
does not specify any hard and soft affiniy in the xl config
file).
This also takes care of the vice-versa, i.e., don't trigger
automatic placement if the config file specifies either an
hard (the check for which was already there) or a soft (the
check for which is introduced by this commit) affinity.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
Changes from v3:
* rephrase comments and docs, as suggestd during review.
---
docs/man/xl.cfg.pod.5 | 21 +++++++++++----------
docs/misc/xl-numa-placement.markdown | 14 ++++++++++++--
tools/libxl/libxl_dom.c | 20 ++++++++++++++++++--
3 files changed, 41 insertions(+), 14 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 08a61da..a97a2b1 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -158,16 +158,6 @@ here, and the soft affinity mask, provided via B<cpus\_soft=> (if any),
is utilized to compute the domain node-affinity, for driving memory
allocations.
-If we are on a NUMA machine (i.e., if the host has more than one NUMA
-node) and this option is not specified, libxl automatically tries to
-place the guest on the least possible number of nodes. That, however,
-will not affect vcpu pinning, so the guest will still be able to run on
-all the cpus. A heuristic approach is used for choosing the best node (or
-set of nodes), with the goals of maximizing performance for the guest
-and, at the same time, achieving efficient utilization of host cpus
-and memory. See F<docs/misc/xl-numa-placement.markdown> for more
-details.
-
=item B<cpus_soft="CPU-LIST">
Exactly as B<cpus=>, but specifies soft affinity, rather than pinning
@@ -182,6 +172,17 @@ the intersection of the soft affinity mask, provided here, and the vcpu
pinning, provided via B<cpus=> (if any), is utilized to compute the
domain node-affinity, for driving memory allocations.
+If this option is not specified (and B<cpus=> is not specified either),
+libxl automatically tries to place the guest on the least possible
+number of nodes. A heuristic approach is used for choosing the best
+node (or set of nodes), with the goal of maximizing performance for
+the guest and, at the same time, achieving efficient utilization of
+host cpus and memory. In that case, the soft affinity of all the vcpus
+of the domain will be set to the pcpus belonging to the NUMA nodes
+chosen during placement.
+
+For more details, see F<docs/misc/xl-numa-placement.markdown>.
+
=back
=head3 CPU Scheduling
diff --git a/docs/misc/xl-numa-placement.markdown b/docs/misc/xl-numa-placement.markdown
index 9d64eae..f863492 100644
--- a/docs/misc/xl-numa-placement.markdown
+++ b/docs/misc/xl-numa-placement.markdown
@@ -126,10 +126,20 @@ or Xen won't be able to guarantee the locality for their memory accesses.
That, of course, also mean the vCPUs of the domain will only be able to
execute on those same pCPUs.
+It is is also possible to have a "cpus\_soft=" option in the xl config file,
+to specify the soft affinity for all the vCPUs of the domain. This affects
+the NUMA placement in the following way:
+
+ * if only "cpus\_soft=" is present, the VM's node-affinity will be equal
+ to the nodes to which the pCPUs in the soft affinity mask belong;
+ * if both "cpus\_soft=" and "cpus=" are present, the VM's node-affinity
+ will be equal to the nodes to which the pCPUs present both in hard and
+ soft affinity belong.
+
### Placing the guest automatically ###
-If no "cpus=" option is specified in the config file, libxl tries
-to figure out on its own on which node(s) the domain could fit best.
+If neither "cpus=" nor "cpus\_soft=" are present in the config file, libxl
+tries to figure out on its own on which node(s) the domain could fit best.
If it finds one (some), the domain's node affinity get set to there,
and both memory allocations and NUMA aware scheduling (for the credit
scheduler and starting from Xen 4.3) will comply with it. Starting from
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91af7f8..3511756 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -248,17 +248,33 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
* some weird error manifests) the subsequent call to
* libxl_domain_set_nodeaffinity() will do the actual placement,
* whatever that turns out to be.
+ *
+ * As far as scheduling is concerned, we achieve NUMA-aware scheduling
+ * by having the results of placement affect the soft affinity of all
+ * the vcpus of the domain. Of course, we want that iff placement is
+ * enabled and actually happens, so we only change info->cpumap_soft to
+ * reflect the placement result if that is the case
*/
if (libxl_defbool_val(info->numa_placement)) {
- if (!libxl_bitmap_is_full(&info->cpumap)) {
+ /* We require both hard and soft affinity not to be set */
+ if (!libxl_bitmap_is_full(&info->cpumap) ||
+ !libxl_bitmap_is_full(&info->cpumap_soft)) {
LOG(ERROR, "Can run NUMA placement only if no vcpu "
- "affinity is specified");
+ "(hard or soft) affinity is specified");
return ERROR_INVAL;
}
rc = numa_place_domain(gc, domid, info);
if (rc)
return rc;
+
+ /*
+ * We change the soft affinity in domain_build_info here, of course
+ * after converting the result of placement from nodes to cpus. the
+ * following call to libxl_set_vcpuaffinity_all_soft() will do the
+ * actual updating of the domain's vcpus' soft affinity.
+ */
+ libxl_nodemap_to_cpumap(ctx, &info->nodemap, &info->cpumap_soft);
}
libxl_domain_set_nodeaffinity(ctx, domid, &info->nodemap);
libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap,
prev parent reply other threads:[~2014-06-10 0:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 0:44 [v7 PATCH 00/10] Implement vcpu soft affinity for credit1 Dario Faggioli
2014-06-10 0:44 ` [v7 PATCH 01/10] xen: sched: rename v->cpu_affinity into v->cpu_hard_affinity Dario Faggioli
2014-06-10 0:44 ` [v7 PATCH 02/10] xen: sched: introduce soft-affinity and use it instead d->node-affinity Dario Faggioli
2014-06-10 11:26 ` George Dunlap
2014-06-10 0:44 ` [v7 PATCH 03/10] xen: derive NUMA node affinity from hard and soft CPU affinity Dario Faggioli
2014-06-10 14:53 ` George Dunlap
2014-06-10 15:20 ` Dario Faggioli
2014-06-10 15:33 ` George Dunlap
2014-06-10 0:44 ` [v7 PATCH 04/10] xen/libxc: sched: DOMCTL_*vcpuaffinity works with hard and soft affinity Dario Faggioli
2014-06-10 0:45 ` [v7 PATCH 05/10] libxc/libxl: bump library SONAMEs Dario Faggioli
2014-06-10 13:46 ` Ian Campbell
2014-06-10 0:45 ` [v7 PATCH 06/10] libxc: get and set soft and hard affinity Dario Faggioli
2014-06-10 0:45 ` [v7 PATCH 07/10] libxl: get and set soft affinity Dario Faggioli
2014-06-10 14:02 ` Ian Campbell
2014-06-11 7:13 ` Dario Faggioli
2014-06-10 15:39 ` George Dunlap
2014-06-10 15:44 ` Ian Campbell
2014-06-10 0:45 ` [v7 PATCH 08/10] xl: enable getting and setting soft Dario Faggioli
2014-06-10 14:10 ` Ian Campbell
2014-06-10 15:10 ` Dario Faggioli
2014-06-10 0:45 ` [v7 PATCH 09/10] xl: enable for specifying soft-affinity in the config file Dario Faggioli
2014-06-10 14:38 ` Ian Campbell
2014-06-10 15:36 ` Dario Faggioli
2014-06-10 15:46 ` Ian Campbell
2014-06-10 0:45 ` Dario Faggioli [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=20140610004545.16660.14597.stgit@Solace \
--to=dario.faggioli@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=George.Dunlap@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.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 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.