Re: [Xen-devel] [PATCH 18/24] xen: credit2: soft-affinity awareness fallback_cpu() and cpu_pick()

[anshul makkar <anshul.makkar@xxxxxxxxxx>]

On 17/08/16 18:19, Dario Faggioli wrote:
> For get_fallback_cpu(), by putting in place the "usual"
> two steps (soft affinity step and hard affinity step)
> loop. We just move the core logic of the function inside
> the body of the loop itself.
>
> For csched2_cpu_pick(), what is important is to find
> the runqueue with the least average load. Currently,
> we do that by looping on all runqueues and checking,
> well, their load. For soft affinity, we want to know
> which one is the runqueue with the least load, among
> the ones where the vcpu would prefer to be assigned.
>
> We find both the least loaded runqueue among the soft
> affinity "friendly" ones, and the overall least loaded
> one, in the same pass.
>
> (Also, kill a spurious ';' when defining MAX_LOAD.)
>
> Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
> Signed-off-by: Justin T. Weaver <jtweaver@xxxxxxxxxx>
> ---
> Cc: George Dunlap <george.dunlap@xxxxxxxxxx>
> Cc: Anshul Makkar <anshul.makkar@xxxxxxxxxx>
> ---
>   xen/common/sched_credit2.c |  136 ++++++++++++++++++++++++++++++++++++--------
>   1 file changed, 111 insertions(+), 25 deletions(-)
>
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 3aef1b4..2d7228a 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -506,34 +506,68 @@ 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,
With remote runqueues , do you mean runqs on remote socket ? Can't we 
just read their workload or we can change the locktype to allow reading ?
> + * 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;
svc's current runqueue. Do you mean the runq in which svc is currently 
queued ?
> + *  3) just one valid pcpu from svc's soft affinity;
> + *  4) svc's current pcpu, if it is part of svc's hard affinity;
> + *  5) a pcpu in svc's current runqueue that is also in svc's hard affinity;
> + *  6) 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.
>    */
>   static int get_fallback_cpu(struct csched2_vcpu *svc)
>   {
>       int cpu;
> +    unsigned int bs;
>
> -    if ( likely(cpumask_test_cpu(svc->vcpu->processor,
> -                                 svc->vcpu->cpu_hard_affinity)) )
> -        return svc->vcpu->processor;
> +    for_each_affinity_balance_step( bs )
> +    {
> +        if ( bs == BALANCE_SOFT_AFFINITY &&
> +             !has_soft_affinity(svc->vcpu, svc->vcpu->cpu_hard_affinity) )
> +            continue;
Anshul

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