All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 0/6] Soft affinity for Credit2
@ 2017-07-27 12:05 Dario Faggioli
  2017-07-27 12:05 ` [PATCH v2 1/6] xen/tools: credit2: soft-affinity awareness in runq_tickle() Dario Faggioli
                   ` (5 more replies)
  0 siblings, 6 replies; 10+ messages in thread
From: Dario Faggioli @ 2017-07-27 12:05 UTC (permalink / raw)
  To: xen-devel
  Cc: George Dunlap, Ian Jackson, Justin T. Weaver, Wei Liu, Anshul Makkar

Hello,

Take 2 of soft-affinity for Credit2. Not much changed actually:
- what was patch 1, it went in, so the series is shorter; :-)
- in patch 5 ("xen: credit2: optimize runq_candidate() a little bit"), I
  changed things according to George's advice;
- patch 2 ("xen: credit2: soft-affinity awareness in gat_fallback_cpu()"),
  is the one that changed most. In that case as well, I've accordingly to
  what we decided during review.

In fact, all the patches have the tags they need to go in already, *except*
patch 2.

v1 was here:

 https://lists.xen.org/archives/html/xen-devel/2017-06/msg01795.html

A git branch is here:

 git://xenbits.xen.org/people/dariof/xen.git rel/sched/credit2-soft-aff-v2
 http://xenbits.xen.org/gitweb/?p=people/dariof/xen.git;a=shortlog;h=refs/heads/rel/sched/credit2-soft-aff-v2
 https://travis-ci.org/fdario/xen/builds/258112860

Regards,
Dario
---
Dario Faggioli (6):
      xen/tools: credit2: soft-affinity awareness in runq_tickle()
      xen: credit2: soft-affinity awareness in gat_fallback_cpu()
      xen: credit2: soft-affinity awareness in csched2_cpu_pick()
      xen: credit2: kick away vcpus not running within their soft-affinity
      xen: credit2: optimize runq_candidate() a little bit
      xen: credit2: try to avoid tickling cpus subject to ratelimiting

 tools/xentrace/formats       |    2 
 tools/xentrace/xenalyze.c    |    7 -
 xen/common/sched_credit2.c   |  506 ++++++++++++++++++++++++++++++++----------
 xen/include/xen/perfc_defn.h |    2 
 4 files changed, 394 insertions(+), 123 deletions(-)
--
<<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)

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

^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [PATCH v2 2/6] xen: credit2: soft-affinity awareness in gat_fallback_cpu()
@ 2017-08-28 18:30 Dario Faggioli
  0 siblings, 0 replies; 10+ messages in thread
From: Dario Faggioli @ 2017-08-28 18:30 UTC (permalink / raw)
  Cc: xen-devel, Justin T. Weaver, George Dunlap, anshul makkar


[-- Attachment #1.1: Type: text/plain, Size: 6620 bytes --]

Il 28 Ago 2017 16:49, George Dunlap <george.dunlap@citrix.com> ha scritto:
On 07/27/2017 01:05 PM, Dario Faggioli wrote:
> By, basically, moving all the logic of the function
> inside the usual two steps (soft-affinity step and
> hard-affinity step) loop.
>
> While there, add two performance counters (in cpu_pick
> and in get_fallback_cpu() itself), in order to be able
> to tell how frequently it happens that we need to look
> for a fallback cpu.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> Signed-off-by: Justin T. Weaver <jtweaver@hawaii.edu>
> ---
> Cc: Anshul Makkar <anshulmakkar@gmail.com>
> Cc: George Dunlap <george.dunlap@eu.citrix.com>
> ---
> Changes from v1:
> - as discussed during review, only consider hard-affinity for the last stand.
>   The idea is not moving the vcpu to a diffrent runqueue because of
>   soft-affinity, as a part of finding a fallback cpu;
> - as discussed during review, added the performance counters;
> - BUG_ON(1) turned into ASSERT_UNREACHABLE(), as suggested during review;
> - return something same and random enough, at the end of the function (in
>   case we somehow manage to get there).
> ---
>  xen/common/sched_credit2.c   |  101 +++++++++++++++++++++++++++++++++---------
>  xen/include/xen/perfc_defn.h |    2 +
>  2 files changed, 82 insertions(+), 21 deletions(-)
>
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 57e77df..aa8f169 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -549,36 +549,93 @@ void smt_idle_mask_clear(unsigned int cpu, cpumask_t *mask)
>  }
>
>  /*
> - * When a hard affinity change occurs, we may not be able to check some
> - * (any!) of the other runqueues, when looking for the best new processor
> - * for svc (as trylock-s in csched2_cpu_pick() can fail). If that happens, we
> - * pick, in order of decreasing preference:
> - *  - svc's current pcpu;
> - *  - another pcpu from svc's current runq;
> - *  - any cpu.
> + * In csched2_cpu_pick(), it may not be possible to actually look at remote
> + * runqueues (the trylock-s on their spinlocks can fail!). If that happens,
> + * we pick, in order of decreasing preference:
> + *  1) svc's current pcpu, if it is part of svc's soft affinity;
> + *  2) a pcpu in svc's current runqueue that is also in svc's soft affinity;
> + *  3) svc's current pcpu, if it is part of svc's hard affinity;
> + *  4) a pcpu in svc's current runqueue that is also in svc's hard affinity;
> + *  5) just one valid pcpu from svc's hard affinity
> + *
> + * Of course, 1, 2 and 3 makes sense only if svc has a soft affinity. Also
> + * note that at least 6 is guaranteed to _always_ return at least one pcpu.

s/6/5/; ?

>   */
>  static int get_fallback_cpu(struct csched2_vcpu *svc)
>  {
>      struct vcpu *v = svc->vcpu;
> -    int cpu = v->processor;
> +    unsigned int bs;
>
> -    cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
> -                cpupool_domain_cpumask(v->domain));
> +    SCHED_STAT_CRANK(need_fallback_cpu);
>
> -    if ( likely(cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu))) )
> -        return cpu;
> -
> -    if ( likely(cpumask_intersects(cpumask_scratch_cpu(cpu),
> -                                   &svc->rqd->active)) )
> +    for_each_affinity_balance_step( bs )
>      {
> -        cpumask_and(cpumask_scratch_cpu(cpu), &svc->rqd->active,
> -                    cpumask_scratch_cpu(cpu));
> -        return cpumask_first(cpumask_scratch_cpu(cpu));
> -    }
> +        int cpu = v->processor;
>
> -    ASSERT(!cpumask_empty(cpumask_scratch_cpu(cpu)));
> +        if ( bs == BALANCE_SOFT_AFFINITY &&
> +             !has_soft_affinity(v, v->cpu_hard_affinity) )
> +            continue;
>
> -    return cpumask_first(cpumask_scratch_cpu(cpu));
> +        affinity_balance_cpumask(v, bs, cpumask_scratch_cpu(cpu));
> +        cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
> +                    cpupool_domain_cpumask(v->domain));
> +
> +        /*
> +         * This is cases 1 or 3 (depending on bs): if v->processor is (still)
> +         * in our affinity, go for it, for cache betterness.
> +         */
> +        if ( likely(cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu))) )
> +            return cpu;
> +
> +        /*
> +         * This is cases 2 or 4 (depending on bs): v->processor isn't there
> +         * any longer, check if we at least can stay in our current runq.
> +         */
> +        if ( likely(cpumask_intersects(cpumask_scratch_cpu(cpu),
> +                                       &svc->rqd->active)) )
> +        {
> +            cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
> +                        &svc->rqd->active);
> +            return cpumask_first(cpumask_scratch_cpu(cpu));
> +        }
> +
> +        /*
> +         * We may well pick any valid pcpu from our soft-affinity, outside
> +         * of our current runqueue, but we decide not to. In fact, changing
> +         * runqueue is slow, affects load distribution, and is a source of
> +         * overhead for the vcpus running on the other runqueue (we need the
> +         * lock). So, better do that as a consequence of a well informed
> +         * decision (or if we really don't have any other chance, as we will,
> +         * at step 6, if we get to there).

s/5/6/;

> +         *
> +         * Also, being here, looking for a fallback, is an unfortunate and
> +         * infrequent event, while the decision of putting us in the runqueue
> +         * wehere we are was (likely) made taking all the relevant factors
> +         * into account. So let's not disrupt that, just for the sake of
> +         * soft-affinity, and let's wait here to be able to made (hopefully,
> +         * soon), another similar well informed decision.
> +         */
> +        if ( bs == BALANCE_SOFT_AFFINITY )
> +            continue;
> +
> +        /*
> +         * This is cases 6: last stand, just one valid pcpu from our hard
> +         * affinity. It's guaranteed that there is at least one valid cpu,
> +         * and therefore we are sure that we return it, and never really
> +         * exit the loop.
> +         */

s/5/6/;

Yes! Sorry for this! :-/

Everything else looks good -- I can fix these up on commit.

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

Great.. and thanks.
Dario

PS. Sorry for the (most likely) bad format of this email (semt from my phone)


[-- Attachment #1.2: Type: text/html, Size: 12429 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2017-08-28 18:31 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-27 12:05 [PATCH v2 0/6] Soft affinity for Credit2 Dario Faggioli
2017-07-27 12:05 ` [PATCH v2 1/6] xen/tools: credit2: soft-affinity awareness in runq_tickle() Dario Faggioli
2017-08-28 14:40   ` George Dunlap
2017-07-27 12:05 ` [PATCH v2 2/6] xen: credit2: soft-affinity awareness in gat_fallback_cpu() Dario Faggioli
2017-08-28 14:49   ` George Dunlap
2017-07-27 12:05 ` [PATCH v2 3/6] xen: credit2: soft-affinity awareness in csched2_cpu_pick() Dario Faggioli
2017-07-27 12:06 ` [PATCH v2 4/6] xen: credit2: kick away vcpus not running within their soft-affinity Dario Faggioli
2017-07-27 12:06 ` [PATCH v2 5/6] xen: credit2: optimize runq_candidate() a little bit Dario Faggioli
2017-07-27 12:06 ` [PATCH v2 6/6] xen: credit2: try to avoid tickling cpus subject to ratelimiting Dario Faggioli
2017-08-28 18:30 [PATCH v2 2/6] xen: credit2: soft-affinity awareness in gat_fallback_cpu() Dario Faggioli

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.