|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/9] xen: sched: make locking for {insert, remove}_vcpu consistent
On Thu, 2015-10-01 at 02:03 -0600, Jan Beulich wrote:
> > > > On 29.09.15 at 18:55, <dario.faggioli@xxxxxxxxxx> wrote:
> > In case of credit1, remove_vcpu() handling needs some
> > fixing remove_vcpu() too, i.e.:
> > - it manipulates runqueues, so the runqueue lock must
> > be acquired;
>
> Is this really a fix needed only as a result of the insert side
> changes? If not, since the insert side looks more like an
> improvement than a bug fix, perhaps splitting the two (and
> requesting backport of the remove side change) would be
> better?
>
Yes, I like the idea, I'll do this.
> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c
> > @@ -905,8 +905,19 @@ csched_vcpu_insert(const struct scheduler
> > *ops, struct vcpu *vc)
> > {
> > struct csched_vcpu *svc = vc->sched_priv;
> >
> > - if ( !__vcpu_on_runq(svc) && vcpu_runnable(vc) && !vc
> > ->is_running )
> > - __runq_insert(vc->processor, svc);
> > + /*
> > + * For the idle domain, this is called, during boot, before
> > + * than alloc_pdata() has been called for the pCPU.
> > + */
> > + if ( !is_idle_vcpu(vc) )
>
> Looking through the patch I can't spot why this would all of the
> sudden need special casing. Can you explain that please? In
> particular (in case it's just the acquiring of the lock that now
> becomes an issue) - where would the runqueue insertion be
> happening now?
>
So, this is an issue in Credit2 (from where the comment was taken) and
RTDS. I've checked further and, for Credit, it is an issue only without
patch 4 of this series, and even in that case, it can be cured in
another (better) way, I think.
So, I'll not only split, but also rework this patch a bit, and
resubmit.
> Or if one of the latter two conditions makes it
> so that insertion turns out not to be needed, perhaps they could
> be moved up to replace the is-idle check?
>
Yes, it was the !vc->is_running part which prevents the insertion of
idle vcpus in runqueues already. I wouldn't like having it guarding the
whole thing, for various reasons, but as I said, I think I can rework
the patch to make things more clear.
> Also, not the least since the comment gets repeated below, if
> it is to stay then I think the "than" should be dropped (or
> re-worded more extensively).
>
Yep, as a part of the rework, I'll reword the comment(s).
Thanks and Regards,
Dario
--
<<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)
Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |