Re: [PATCH 3/3] xen: credit1: avoid boosting vCPUs being "just" migrated

[Dario Faggioli <dario.faggioli@citrix.com>]

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

On Thu, 2016-02-11 at 06:30 -0700, Jan Beulich wrote:
> > > > On 11.02.16 at 12:39, <dario.faggioli@citrix.com> wrote:
> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c
> > @@ -1022,11 +1022,14 @@ csched_vcpu_wake(const struct scheduler
> > *ops, struct vcpu *vc, unsigned wf)
> >       * more CPU resource intensive VCPUs without impacting
> > overall 
> >       * system fairness.
> >       *
> > -     * The one exception is for VCPUs of capped domains unpausing
> > -     * after earning credits they had overspent. We don't boost
> > -     * those.
> > +     * There are a couple of exceptions, when we don't want to
> > boost:
> > +     *  - VCPUs that are waking up after a migration, rather than
> > +     *    after having block;
> > +     *  - VCPUs of capped domains unpausing after earning credits
> > +     *    they had overspent.
> >       */
> > -    if ( svc->pri == CSCHED_PRI_TS_UNDER &&
> > +    if ( !(wf & WF_migrated) &&
> > +         svc->pri == CSCHED_PRI_TS_UNDER &&
> >           !test_bit(CSCHED_FLAG_VCPU_PARKED, &svc->flags) )
> >      {
> 
> Considering the other svc->flags check done here, wouldn't it be
> possible to achieve the same effect without patch 2, by having
> csched_cpu_pick() set a newly defined flag, and check for it here?
> 
It can indeed. I've coded it up, and I like the way it came out better.

I'm rerunning the benchmarks right now (just in case! :-)). I'll send
v2 out as soon as they finish.

I did like the idea of "wakeup flags", and I think they may actually
turn out useful, but they're not necessary for this specific use case,
as it appears. Well, next time. ;-)

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

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