|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RESEND 12/12] xl: numa-sched: enable specifying node-affinity in VM config file
On gio, 2013-11-07 at 18:35 +0000, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH RESEND 12/12] xl: numa-sched: enable
> specifying node-affinity in VM config file"):
> > in a similar way to how it is possible to specify vcpu-affinity.
> ...
> > /*
> > - * Check if the domain has any CPU affinity. If not, try to build
> > - * up one. In case numa_place_domain() find at least a suitable
> > - * candidate, it will affect info->nodemap accordingly; if it
> > - * does not, it just leaves it as it is. This means (unless
> > - * some weird error manifests) the subsequent call to
> > - * libxl_domain_set_nodeaffinity() will do the actual placement,
> > + * Check if the domain has any pinning or node-affinity and, if not,
> > try
> > + * to build up one.
> > + *
> > + * In case numa_place_domain() find at least a suitable candidate, it
> > will
> > + * affect info->nodemap accordingly; if it does not, it just leaves it
> > as
> > + * it is. This means (unless some weird error manifests) the subsequent
> > + * call to libxl_domain_set_nodeaffinity() will do the actual
> > placement,
> > * whatever that turns out to be.
> > */
> > if (libxl_defbool_val(info->numa_placement)) {
> >
> > - if (!libxl_bitmap_is_full(&info->cpumap)) {
> > + if (!libxl_bitmap_is_full(&info->cpumap) ||
> > + !libxl_bitmap_is_full(&info->nodemap)) {
> > LOG(ERROR, "Can run NUMA placement only if no vcpu "
> > - "affinity is specified");
> > + "pinning or node-affinity is specified");
>
> I appreciate I may be a bit late with this complaint, but surely this
> approach (setting the cpumap and nodemap when they aren't
> all-bits-set) means that it's not possible to explicitly set "all
> cpus".
>
The funny part is not that you're late, but to whom you're saying
it! :-D :-D
http://lists.xen.org/archives/html/xen-devel/2012-07/msg01077.html
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Mon, 23 Jul 2012 12:04:29 +0100
Dario Faggioli writes ("[PATCH 2 of 4 v6/leftover] xl: inform libxl if there
was a cpumap in the config file"):
[...]
Shouldn't this be
- if (libxl_bitmap_is_full(&info->cpumap)) {
+ if (libxl_defbool_val(info->numa_placement)) {
+ if (!libxl_bitmap_is_full(&info->cpumap)) {
+ rc = ERROR_INVAL;
+ LOG blah blah invalid not supported
+ goto out;
+ }
The story behind all this is that, back at that time, someone (and I'm
sure it's you again, although I don't find the thread now) asked to
introduce info->numa_placement, to have a mean for: (1) disabling NUMA
placement completely; (2) help distinguishing the case where cpumap is
full because we want "cpus=all" from the one where it's full because we
did not touched it, since being full is the default value.
I remember finding it sound, and thus going for it. Perhaps we could
have done it differently, but given that info->cpumap is full by
default, I really don't see that many alternatives (apart from making
cpumap empty by default, which may look even weirder).
So, the idea here is:
- if it's full, and placement is enabled, full means "do this for me",
and that's what happens.
- if placement is disabled, then nobody touches it, so if it was full
it stay that way.
So, for saying "all", the procedure is as follows:
info->numa_placement = false;
fill_bitmap(info->cpumap);
> If I say in the config file "all" for cpus and "all" for nodes, this
> code will override that. I don't think that can be right.
>
And in fact, xl, when parsing the config file, turns numa_placement to
false when finding a "cpus=" item.
All the above applies to the new "nodes=" switch as well, of course.
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:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |