From: George Dunlap <george.dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Dario Faggioli <dario.faggioli@citrix.com>
Subject: Re: [PATCH v2] credit: generalize __vcpu_has_soft_affinity()
Date: Fri, 6 Mar 2015 12:00:30 +0000 [thread overview]
Message-ID: <54F996DE.6010203@eu.citrix.com> (raw)
In-Reply-To: <54F9A13C0200007800066FD4@mail.emea.novell.com>
On 03/06/2015 11:44 AM, Jan Beulich wrote:
>>>> On 06.03.15 at 12:32, <george.dunlap@eu.citrix.com> wrote:
>> On 03/06/2015 10:16 AM, Jan Beulich wrote:
>>>>>> On 06.03.15 at 10:53, <george.dunlap@eu.citrix.com> wrote:
>>>> On 03/06/2015 07:36 AM, Jan Beulich wrote:
>>>>> As pointed out in the discussion of the patch at
>>>>> http://lists.xenproject.org/archives/html/xen-devel/2015-02/msg03256.html
>>>>> generalizing the conditions here means code elsewhere doesn't need to
>>>>> take into consideration internals of how load balancing in the credit
>>>>> scheduler works.
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>> ---
>>>>> v2: Use VCPU2ONLINE(vc) (or really an open coded variant thereof)
>>>>> instead of cpu_online_map (suggested by Dario).
>>>>>
>>>>> --- a/xen/common/sched_credit.c
>>>>> +++ b/xen/common/sched_credit.c
>>>>> @@ -292,11 +292,10 @@ __runq_remove(struct csched_vcpu *svc)
>>>>> static inline int __vcpu_has_soft_affinity(const struct vcpu *vc,
>>>>> const cpumask_t *mask)
>>>>> {
>>>>> - if ( cpumask_full(vc->cpu_soft_affinity)
>>>>> - || !cpumask_intersects(vc->cpu_soft_affinity, mask) )
>>>>> - return 0;
>>>>> -
>>>>> - return 1;
>>>>> + return !cpumask_subset(cpupool_online_cpumask(vc->domain->cpupool),
>>>>> + vc->cpu_soft_affinity) &&
>>>>> + !cpumask_subset(vc->cpu_soft_affinity, vc->cpu_hard_affinity) &&
>>>>> + cpumask_intersects(vc->cpu_soft_affinity, mask);
>>>>
>>>> It looks like the comment above this line could use changing too; perhaps:
>>>>
>>>> ---
>>>> Hard affinity balancing is always necessary and must never be skipped.
>>>> But soft affinity need only be considered when it has a functionally
>>>> different effect than other constraints (such as hard affinity, cpus
>>>> online, or cpupools).
>>>>
>>>> Soft affinity only needs to be considered if:
>>>> * The cpus in the cpupool are not a subset of soft affinity
>>>> * The hard affinity is not a subset of soft affinity
>>>
>>> "hard" and "soft" appear to be swapped here. I corrected this,
>>> please let me know if you disagree (in which case the patch would
>>> need changing too).
>>
>> Uum -- I think my comment is right. If the soft affinity is a subset of
>> hard affinity, then there are some cpus in the hard affinity which are
>> "preferred" (soft affine) and some that are "not preferred"
>> (non-soft-affine). Whereas, if hard affinity is a subset of soft
>> affinity, then all cpus in the hard affinity are "preffered" (soft
>> affine), and so there's no sense in doing the soft affinity step.
>
> I.e. confusion about which affinity means what is ongoing:
> Earlier on we had Dario answering a question of mine
>
>>> Hmm, not sure. And I keep being confused whether soft means
>>> "allow" and hard means "prefer" or the other way around.
>>>
>> "hard" means allow (or not allow)
>> "soft" means prefer
>
> while I read your reply to mean the opposite.
No, Dario and I mean the same thing: "Hard affinity" means "May only run
on these cpus and no others". "Soft affinity" means "I prefer you to
run here if you can, but if it's too busy, go ahead and run it somewhere
else".
Hard affinity replaces what used to be called "vcpu_affinity"; and soft
affinity is typically used for vNUMA implementation.
Consider the following example
Soft affinity: 00001100
Hard affinity: 00111100
In this case, the scheduler should *prefer* to run it on cpus 4 or 5
(which is in both the soft and hard affinities), but *may* run it on
cpus 2-3 if it thinks it's necessary; so there is an "effective soft
affinity" -- even though soft affinity is a subset of hard affinity.
Now consider the reverse:
Soft affinity: 00111100
Hard affinity: 00001100
In this case, the scheduler *must* run it on either cpus 4 or 5; but
there is no preference between the two, since both are in the soft
affinity set. So this is effectively the same as not having any soft
affinity. And hard affinity is a subset of soft affinity.
-George
next prev parent reply other threads:[~2015-03-06 12:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-06 7:36 [PATCH v2] credit: generalize __vcpu_has_soft_affinity() Jan Beulich
2015-03-06 8:39 ` Dario Faggioli
2015-03-06 9:53 ` George Dunlap
2015-03-06 10:16 ` Jan Beulich
2015-03-06 11:32 ` George Dunlap
2015-03-06 11:44 ` Jan Beulich
2015-03-06 12:00 ` George Dunlap [this message]
2015-03-06 13:10 ` Jan Beulich
2015-03-06 13:23 ` Dario Faggioli
2015-03-06 13:32 ` Jan Beulich
2015-03-06 13:44 ` Dario Faggioli
2015-03-06 11:12 ` Dario Faggioli
2015-03-06 11:38 ` George Dunlap
2015-03-06 13:31 ` Dario Faggioli
2015-03-06 14:57 ` George Dunlap
2015-03-06 15:10 ` Dario Faggioli
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=54F996DE.6010203@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=dario.faggioli@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 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.