xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>,
	xen-devel@lists.xenproject.org
Cc: Anshul Makkar <anshul.makkar@citrix.com>
Subject: Re: [PATCH 5/7] xen: credit2: kick away vcpus not running within their soft-affinity
Date: Tue, 25 Jul 2017 12:06:06 +0100	[thread overview]
Message-ID: <c9f2a337-503f-e66a-d61e-30980b8c03bb@citrix.com> (raw)
In-Reply-To: <149762245143.11899.458751530098326746.stgit@Solace.fritz.box>

On 06/16/2017 03:14 PM, Dario Faggioli wrote:
> If, during scheduling, we realize that the current vcpu
> is running outside of its own soft-affinity, it would be
> preferable to send it somewhere else.
> 
> Of course, that may not be possible, and if we're too
> strict, we risk having vcpus sit in runqueues, even if
> there are idle pcpus (violating work-conservingness).
> In fact, what about there are no pcpus, from the soft
> affinity mask of the vcpu in question, where it can
> run?
> 
> To make sure we don't fall in the above described trap,
> only actually de-schedule the vcpu if there are idle and
> not already tickled cpus from its soft affinity where it
> can run immediately.
> 
> If there is (at least one) of such cpus, we let current
> be preempted, so that csched2_context_saved() will put
> it back in the runq, and runq_tickle() will wake (one
> of) the cpu.
> 
> If there is not even one, we let current run where it is,
> as running outside its soft-affinity is still better than
> not running at all.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

*This* one looks good:

Reviewed-by: George Dunlap <george.dunlap@citrix.com>

> ---
> Cc: George Dunlap <george.dunlap@citrix.com>
> Cc: Anshul Makkar <anshul.makkar@citrix.com>
> ---
>  xen/common/sched_credit2.c |   40 ++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 38 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index fb97ff7..5d8f25c 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -2637,6 +2637,7 @@ runq_candidate(struct csched2_runqueue_data *rqd,
>      struct csched2_vcpu *snext = NULL;
>      struct csched2_private *prv = csched2_priv(per_cpu(scheduler, cpu));
>      bool yield = __test_and_clear_bit(__CSFLAG_vcpu_yield, &scurr->flags);
> +    bool soft_aff_preempt = false;
>  
>      *skipped = 0;
>  
> @@ -2670,8 +2671,43 @@ runq_candidate(struct csched2_runqueue_data *rqd,
>          return scurr;
>      }
>  
> -    /* Default to current if runnable, idle otherwise */
> -    if ( vcpu_runnable(scurr->vcpu) )
> +    /* If scurr has a soft-affinity, let's check whether cpu is part of it */
> +    if ( !is_idle_vcpu(scurr->vcpu) &&
> +         has_soft_affinity(scurr->vcpu, scurr->vcpu->cpu_hard_affinity) )
> +    {
> +        affinity_balance_cpumask(scurr->vcpu, BALANCE_SOFT_AFFINITY,
> +                                 cpumask_scratch);
> +        if ( unlikely(!cpumask_test_cpu(cpu, cpumask_scratch)) )
> +        {
> +            cpumask_t *online = cpupool_domain_cpumask(scurr->vcpu->domain);
> +
> +            /* Ok, is any of the pcpus in scurr soft-affinity idle? */
> +            cpumask_and(cpumask_scratch, cpumask_scratch, &rqd->idle);
> +            cpumask_andnot(cpumask_scratch, cpumask_scratch, &rqd->tickled);
> +            soft_aff_preempt = cpumask_intersects(cpumask_scratch, online);
> +        }
> +    }
> +
> +    /*
> +     * If scurr is runnable, and this cpu is in its soft-affinity, default to
> +     * it. We also default to it, even if cpu is not in its soft-affinity, if
> +     * there aren't any idle and not tickled cpu in its soft-affinity. In
> +     * fact, we don't want to risk leaving scurr in the runq and this cpu idle
> +     * only because scurr is running outside of its soft-affinity.
> +     *
> +     * On the other hand, if cpu is not in scurr's soft-affinity, and there
> +     * looks to be better options, go for them. That happens by defaulting to
> +     * idle here, which means scurr will be preempted, put back in runq, and
> +     * one of those idle and not tickled cpus from its soft-affinity will be
> +     * tickled to pick it up.
> +     *
> +     * Finally, if scurr does not have a valid soft-affinity, we also let it
> +     * continue to run here (in fact, soft_aff_preempt will still be false,
> +     * in this case).
> +     *
> +     * Of course, we also default to idle also if scurr is not runnable.
> +     */
> +    if ( vcpu_runnable(scurr->vcpu) && !soft_aff_preempt )
>          snext = scurr;
>      else
>          snext = csched2_vcpu(idle_vcpu[cpu]);
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-07-25 11:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-16 14:13 [PATCH 0/7] Soft affinity for Credit2 Dario Faggioli
2017-06-16 14:13 ` [PATCH 1/7] xen: sched: factor affinity helpers out of sched_credit.c Dario Faggioli
2017-06-23 10:02   ` Anshul Makkar
2017-06-23 13:33     ` Dario Faggioli
2017-06-16 14:13 ` [PATCH 2/7] xen/tools: credit2: soft-affinity awareness in runq_tickle() Dario Faggioli
2017-06-23 10:35   ` Anshul Makkar
2017-07-25 11:47   ` George Dunlap
2017-06-16 14:13 ` [PATCH 3/7] xen: credit2: soft-affinity awareness in fallback_cpu() Dario Faggioli
2017-07-25 10:19   ` George Dunlap
2017-07-25 10:20     ` George Dunlap
2017-07-25 16:00     ` Dario Faggioli
2017-07-25 16:17       ` George Dunlap
2017-07-25 16:47         ` Dario Faggioli
2017-07-25 16:52           ` George Dunlap
2017-07-25 17:30             ` Dario Faggioli
2017-06-16 14:14 ` [PATCH 4/7] xen: credit2: soft-affinity awareness in csched2_cpu_pick() Dario Faggioli
2017-07-25 10:54   ` George Dunlap
2017-07-25 11:04   ` George Dunlap
2017-07-25 11:05     ` George Dunlap
2017-06-16 14:14 ` [PATCH 5/7] xen: credit2: kick away vcpus not running within their soft-affinity Dario Faggioli
2017-07-25 11:06   ` George Dunlap [this message]
2017-06-16 14:14 ` [PATCH 6/7] xen: credit2: optimize runq_candidate() a little bit Dario Faggioli
2017-07-25 11:25   ` George Dunlap
2017-06-16 14:14 ` [PATCH 7/7] xen: credit2: try to avoid tickling cpus subject to ratelimiting Dario Faggioli
2017-07-25 11:31   ` 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=c9f2a337-503f-e66a-d61e-30980b8c03bb@citrix.com \
    --to=george.dunlap@citrix.com \
    --cc=anshul.makkar@citrix.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 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).