dependences for backporting to 4.6 [was: Re: [PATCH 2/3] xen: Have schedulers revise initial placement]

["Jan Beulich" <JBeulich@suse.com>]

>>> On 12.08.16 at 03:59, <dario.faggioli@citrix.com> wrote:
> On Fri, 2016-08-05 at 07:24 -0600, Jan Beulich wrote:
>> I'd really like to have those backported, but I have to ask one
>> of you to identify which prereq-s are needed on 4.6 and 4.5
>> (I'll revert them from 4.5 right away, but I'll wait for an osstest
>> flight to confirm the same issue exists on 4.6).
>>
> So, for 4.6, I think the only prerequisite would be this:
> 
> 6b53bb4ab3c9bd5eccde88a5175cf72589ba6d52
> "sched: better handle (not) inserting idle vCPUs in runqueues"
> 
> That, however, does not apply cleanly. The important part of it is the
> last hunk:
> 
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 92057eb..c195129 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -240,20 +240,22 @@ int sched_init_vcpu(struct vcpu *v, unsigned int 
> processor)
>      init_timer(&v->poll_timer, poll_timer_fn,
>                 v, v->processor);
>  
> -    /* Idle VCPUs are scheduled immediately. */
> +    v->sched_priv = SCHED_OP(DOM2OP(d), alloc_vdata, v, d->sched_priv);
> +    if ( v->sched_priv == NULL )
> +        return 1;
> +
> +    TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, v->vcpu_id);
> +
> +    /* Idle VCPUs are scheduled immediately, so don't put them in runqueue. 
> */
>      if ( is_idle_domain(d) )
>      {
>          per_cpu(schedule_data, v->processor).curr = v;
>          v->is_running = 1;
>      }
> -
> -    TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, v->vcpu_id);
> -
> -    v->sched_priv = SCHED_OP(DOM2OP(d), alloc_vdata, v, d->sched_priv);
> -    if ( v->sched_priv == NULL )
> -        return 1;
> -
> -    SCHED_OP(DOM2OP(d), insert_vcpu, v);
> +    else
> +    {
> +        SCHED_OP(DOM2OP(d), insert_vcpu, v);
> +    }
>  
>      return 0;
>  }
> 
> With this only applied, things works for me. The hunk is actually the
> core of the patch, the only real functionality change. The other hunks
> are refactoring and cleanups (made possible by it).
> 
> So, I'm not sure whether the best route here is:
>  - fully backport 6b53bb4ab3c9b;
>  - backport only the last hunk of 6b53bb4ab3c9b as its own patch;
>  - fold the last hunk of 6b53bb4ab3c9b in the backport of George's 
>    patch (I mean, what was 83dff3992a89 in staging-4.6);
> 
> Thoughts?

First of all - thanks a lot for helping out here. With above extra
commit things are indeed back to normal again for me. Since the
adjustments to that commit to make it apply were mostly
mechanical, I think I'd prefer taking the entire backport. Same
for 4.5 then, were the backport adjusted for 4.6 then applied
cleanly.

Jan


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