xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>, xen-devel@lists.xen.org
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Li Yechen <lccycc123@gmail.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Justin Weaver <jtweaver@hawaii.edu>, Matt Wilson <msw@amazon.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: Re: [PATCH v2 08/16] xen: derive NUMA node affinity from hard and soft CPU affinity
Date: Thu, 14 Nov 2013 15:21:40 +0000	[thread overview]
Message-ID: <5284EA84.30506@eu.citrix.com> (raw)
In-Reply-To: <20131113191214.18086.51921.stgit@Solace>

On 13/11/13 19:12, Dario Faggioli wrote:
> if a domain's NUMA node-affinity (which is what controls
> memory allocations) is provided by the user/toolstack, it
> just is not touched. However, if the user does not say
> anything, leaving it all to Xen, let's compute it in the
> following way:
>
>   1. cpupool's cpus & hard-affinity & soft-affinity
>   2. if (1) is empty: cpupool's cpus & hard-affinity
>
> This guarantees memory to be allocated from the narrowest
> possible set of NUMA nodes, ad makes it relatively easy to
> set up NUMA-aware scheduling on top of soft affinity.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> ---
>   xen/common/domain.c |   22 +++++++++++++++++++++-
>   1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 2916490..4b8fca8 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -353,7 +353,7 @@ struct domain *domain_create(
>   
>   void domain_update_node_affinity(struct domain *d)
>   {
> -    cpumask_var_t cpumask;
> +    cpumask_var_t cpumask, cpumask_soft;
>       cpumask_var_t online_affinity;
>       const cpumask_t *online;
>       struct vcpu *v;
> @@ -361,9 +361,15 @@ void domain_update_node_affinity(struct domain *d)
>   
>       if ( !zalloc_cpumask_var(&cpumask) )
>           return;
> +    if ( !zalloc_cpumask_var(&cpumask_soft) )
> +    {
> +        free_cpumask_var(cpumask);
> +        return;
> +    }
>       if ( !alloc_cpumask_var(&online_affinity) )
>       {
>           free_cpumask_var(cpumask);
> +        free_cpumask_var(cpumask_soft);
>           return;
>       }
>   
> @@ -373,8 +379,12 @@ void domain_update_node_affinity(struct domain *d)
>   
>       for_each_vcpu ( d, v )
>       {
> +        /* Build up the mask of online pcpus we have hard affinity with */
>           cpumask_and(online_affinity, v->cpu_hard_affinity, online);
>           cpumask_or(cpumask, cpumask, online_affinity);
> +
> +        /* As well as the mask of all pcpus we have soft affinity with */
> +        cpumask_or(cpumask_soft, cpumask_soft, v->cpu_soft_affinity);

Is this really the most efficient way to do this?  I would have thought 
or'ing cpumask and cpumask_soft, and then if it's not empty, then use 
it; maybe use a pointer so you don't have to copy one into the other one?

Also, all of the above computation happens unconditionally, but is only 
used if d->auto_node_affinity is true.  It seems like it would be better 
to move this calculation inside the conditional.

Leaving the allocation outside might make sense to reduce the code 
covered by the lock -- not sure about that; I don't think this is a 
heavily-contended lock, is it?

>       }
>   
>       /*
> @@ -386,6 +396,15 @@ void domain_update_node_affinity(struct domain *d)
>        */
>       if ( d->auto_node_affinity )
>       {
> +        /*
> +         * We're looking for the narower possible set of nodes. So, if
> +         * possible (i.e., if not empty!) let's use the intersection
> +         * between online, hard and soft affinity. If not, just fall back
> +         * to online & hard affinity.
> +         */
> +        if ( cpumask_intersects(cpumask, cpumask_soft) )
> +            cpumask_and(cpumask, cpumask, cpumask_soft);
> +
>           nodes_clear(d->node_affinity);
>           for_each_online_node ( node )
>               if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
> @@ -397,6 +416,7 @@ void domain_update_node_affinity(struct domain *d)
>       spin_unlock(&d->node_affinity_lock);



>   
>       free_cpumask_var(online_affinity);
> +    free_cpumask_var(cpumask_soft);
>       free_cpumask_var(cpumask);
>   }
>   
>

  reply	other threads:[~2013-11-14 15:21 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-13 19:10 [PATCH v2 00/16] Implement vcpu soft affinity for credit1 Dario Faggioli
2013-11-13 19:11 ` [PATCH v2 01/16] xl: match output of vcpu-list with pinning syntax Dario Faggioli
2013-11-14 10:50   ` George Dunlap
2013-11-14 11:11     ` Dario Faggioli
2013-11-14 11:14       ` George Dunlap
2013-11-14 11:13     ` Dario Faggioli
2013-11-14 12:44     ` Ian Jackson
2013-11-14 14:19   ` Ian Jackson
2013-11-13 19:11 ` [PATCH v2 02/16] xl: allow for node-wise specification of vcpu pinning Dario Faggioli
2013-11-14 11:02   ` George Dunlap
2013-11-14 14:24   ` Ian Jackson
2013-11-14 14:37     ` Dario Faggioli
2013-11-13 19:11 ` [PATCH v2 03/16] xl: implement and enable dryrun mode for `xl vcpu-pin' Dario Faggioli
2013-11-13 19:11 ` [PATCH v2 04/16] xl: test script for the cpumap parser (for vCPU pinning) Dario Faggioli
2013-11-13 19:11 ` [PATCH v2 05/16] xen: fix leaking of v->cpu_affinity_saved Dario Faggioli
2013-11-14 11:11   ` George Dunlap
2013-11-14 11:58     ` Dario Faggioli
2013-11-14 14:25   ` Ian Jackson
2013-11-13 19:11 ` [PATCH v2 06/16] xen: sched: make space for cpu_soft_affinity Dario Faggioli
2013-11-14 15:03   ` George Dunlap
2013-11-14 16:14     ` Dario Faggioli
2013-11-15 10:07       ` George Dunlap
2013-11-13 19:12 ` [PATCH v2 07/16] xen: sched: rename v->cpu_affinity into v->cpu_hard_affinity Dario Faggioli
2013-11-14 14:17   ` George Dunlap
2013-11-13 19:12 ` [PATCH v2 08/16] xen: derive NUMA node affinity from hard and soft CPU affinity Dario Faggioli
2013-11-14 15:21   ` George Dunlap [this message]
2013-11-14 16:30     ` Dario Faggioli
2013-11-15 10:52       ` George Dunlap
2013-11-15 14:17         ` Dario Faggioli
2013-11-13 19:12 ` [PATCH v2 09/16] xen: sched: DOMCTL_*vcpuaffinity works with hard and soft affinity Dario Faggioli
2013-11-14 14:42   ` George Dunlap
2013-11-14 16:21     ` Dario Faggioli
2013-11-13 19:12 ` [PATCH v2 10/16] xen: sched: use soft-affinity instead of domain's node-affinity Dario Faggioli
2013-11-14 15:30   ` George Dunlap
2013-11-15  0:39     ` Dario Faggioli
2013-11-15 11:23       ` George Dunlap
2013-11-13 19:12 ` [PATCH v2 11/16] libxc: get and set soft and hard affinity Dario Faggioli
2013-11-14 14:58   ` Ian Jackson
2013-11-14 16:18     ` Dario Faggioli
2013-11-14 15:38   ` George Dunlap
2013-11-14 16:41     ` Dario Faggioli
2013-11-13 19:12 ` [PATCH v2 12/16] libxl: get and set soft affinity Dario Faggioli
2013-11-13 19:16   ` Dario Faggioli
2013-11-14 15:11   ` Ian Jackson
2013-11-14 15:55     ` George Dunlap
2013-11-14 16:25       ` Ian Jackson
2013-11-15  5:13         ` Dario Faggioli
2013-11-15 12:02         ` George Dunlap
2013-11-15 17:29           ` Dario Faggioli
2013-11-15  3:45     ` Dario Faggioli
2013-11-13 19:12 ` [PATCH v2 13/16] xl: show soft affinity in `xl vcpu-list' Dario Faggioli
2013-11-14 15:12   ` Ian Jackson
2013-11-13 19:13 ` [PATCH v2 14/16] xl: enable setting soft affinity Dario Faggioli
2013-11-13 19:13 ` [PATCH v2 15/16] xl: enable for specifying node-affinity in the config file Dario Faggioli
2013-11-14 15:14   ` Ian Jackson
2013-11-14 16:12     ` Dario Faggioli
2013-11-13 19:13 ` [PATCH v2 16/16] libxl: automatic NUMA placement affects soft affinity Dario Faggioli
2013-11-14 15:17   ` Ian Jackson
2013-11-14 16:11     ` Dario Faggioli
2013-11-14 16:03   ` George Dunlap
2013-11-14 16:48     ` Dario Faggioli
2013-11-14 17:49       ` George Dunlap

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=5284EA84.30506@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=Marcus.Granado@eu.citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=jtweaver@hawaii.edu \
    --cc=juergen.gross@ts.fujitsu.com \
    --cc=keir@xen.org \
    --cc=lccycc123@gmail.com \
    --cc=msw@amazon.com \
    --cc=ufimtseva@gmail.com \
    --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 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).