Re: [PATCH v2 4/5] xen: sched_null: support for hard affinity

[George Dunlap <george.dunlap@citrix.com>]

On 07/04/17 01:34, Dario Faggioli wrote:
> As a (rudimental) way of directing and affecting the
> placement logic implemented by the scheduler, support
> vCPU hard affinity.
> 
> Basically, a vCPU will now be assigned only to a pCPU
> that is part of its own hard affinity. If such pCPU(s)
> is (are) busy, the vCPU will wait, like it happens
> when there are no free pCPUs.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

[snip]

> @@ -413,7 +431,6 @@ static void null_vcpu_insert(const struct scheduler *ops, struct vcpu *v)
>  static void _vcpu_remove(struct null_private *prv, struct vcpu *v)
>  {
>      unsigned int cpu = v->processor;
> -    struct domain *d = v->domain;
>      struct null_vcpu *wvc;
>  
>      ASSERT(list_empty(&null_vcpu(v)->waitq_elem));
> @@ -425,7 +442,7 @@ static void _vcpu_remove(struct null_private *prv, struct vcpu *v)
>       * If yes, we assign it to cpu, in spite of v.
>       */
>      wvc = list_first_entry_or_null(&prv->waitq, struct null_vcpu, waitq_elem);
> -    if ( wvc && cpumask_test_cpu(cpu, cpupool_domain_cpumask(d)) )
> +    if ( wvc && vcpu_check_affinity(wvc->vcpu, cpu) )

Hmm, actually I just noticed that this only checks the first item on the
list.  If there are two vcpus on the list, and the first one doesn't
have affinity with the vcpu in question, the second one won't even be
considered.  This was probably OK in the previous case, where the only
time the test could fail is during suspend/resume, but it's not really
OK anymore, I don't think.

Everything else looks OK to me.

 -George


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