On Thu, 2016-02-11 at 06:30 -0700, Jan Beulich wrote:
> > > > On 11.02.16 at 12:39, <dario.faggi...@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)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
