From: George Dunlap <george.dunlap@eu.citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
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>,
xen-devel@lists.xen.org, Jan Beulich <JBeulich@suse.com>,
Justin Weaver <jtweaver@hawaii.edu>, Matt Wilson <msw@amazon.com>,
Elena Ufimtseva <ufimtseva@gmail.com>
Subject: Re: [PATCH v2 10/16] xen: sched: use soft-affinity instead of domain's node-affinity
Date: Fri, 15 Nov 2013 11:23:52 +0000 [thread overview]
Message-ID: <52860448.8060807@eu.citrix.com> (raw)
In-Reply-To: <1384475989.16918.93.camel@Solace>
On 15/11/13 00:39, Dario Faggioli wrote:
> On gio, 2013-11-14 at 15:30 +0000, George Dunlap wrote:
>> On 13/11/13 19:12, Dario Faggioli wrote:
>>> [..]
>>> The high level description of NUMA placement and scheduling in
>>> docs/misc/xl-numa-placement.markdown is being updated too, to match
>>> the new architecture.
>>>
>>> signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>> Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
>>
> Cool, thanks.
>
>> Just a few things to note below...
>>
> Ok.
>
>>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>>> @@ -411,8 +411,6 @@ void domain_update_node_affinity(struct domain *d)
>>> node_set(node, d->node_affinity);
>>> }
>>>
>>> - sched_set_node_affinity(d, &d->node_affinity);
>>> -
>>> spin_unlock(&d->node_affinity_lock);
>> At this point, the only thing inside the spinlock is contingent on
>> d->auto_node_affinity.
>>
> Mmm... Sorry, but I'm not geting what you mean here. :-(
I mean just what I said -- if d->auto_node_affinity is false, nothing
inside the critical region here needs to be done. I'm just pointing it
out. :-) (This is sort of related to my comment on the other patch,
about not needing to do the work of calculating intersections.)
>
>>> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
>>> -static inline int __vcpu_has_node_affinity(const struct vcpu *vc,
>>> +static inline int __vcpu_has_soft_affinity(const struct vcpu *vc,
>>> const cpumask_t *mask)
>>> {
>>> - const struct domain *d = vc->domain;
>>> - const struct csched_dom *sdom = CSCHED_DOM(d);
>>> -
>>> - if ( d->auto_node_affinity
>>> - || cpumask_full(sdom->node_affinity_cpumask)
>>> - || !cpumask_intersects(sdom->node_affinity_cpumask, mask) )
>>> + if ( cpumask_full(vc->cpu_soft_affinity)
>>> + || !cpumask_intersects(vc->cpu_soft_affinity, mask) )
>>> return 0;
>> At this point we've lost a way to make this check potentially much
>> faster (being able to check auto_node_affinity).
>>
> Right.
>
>> This isn't a super-hot
>> path but it does happen fairly frequently --
>>
> Quite frequently indeed.
>
>> will the "cpumask_full()"
>> check take a significant amount of time on, say, a 4096-core system? If
>> so, we might think about "caching" the results of cpumask_full() at some
>> point.
>>
> Yes, I think cpumask_* operation could be heavy when the number of pcpus
> is high. However, this is not really a problem introduced by this
> series. Consider that the default behavior (for libxl and xl) is to go
> through initial domain placement, which would set a node-affinity for
> the domain explicitly, which means d->auto_node_affinity is false.
>
> In fact, every domain that does not manually pin its vcpus at creation
> time --which is what we want, because that way NUMA placement can do its
> magic-- will have to go through the (cpumask_full || !cpumask_intrscts)
> anyway. Basically, I'm saying that having d->auto_node_affinity there
> may look like a speedup, but it really is only for a minority of cases.
>
> So, yes, I think we should aim at optimizing this, but that is something
> completely orthogonal to this series. That is to say: (a) we should do
> it anyway, whether or not this series goes in; (b) for that same reason,
> that shouldn't prevent this series from going in.
>
> If you think this can be an issue for 4.4, I'm fine creating a bug for
> it and putting it among the blockers. At that point, I'll start looking
> for a solution, and will commit to post a fix ASAP, but again, that's
> pretty independent from this very series, at least AFAICT.
>
> Then, the fact that you provided your Reviewed-by above probably means
> that you are aware and ok with this all, but I felt like it was worth
> pointing it out anyway. :-)
Yes, the "at some point" was intended to imply that I didn't think this
had to be done right away, as was "things to note", which means, "I just
want to point this out, they're not something which needs to be acted on
right away."
-George
next prev parent reply other threads:[~2013-11-15 11:23 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
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 [this message]
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=52860448.8060807@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).