[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control scheduling frequency
On Mon, 2011-12-19 at 22:13 +0000, Hui Lv wrote: > 1. Basically, the "delay method" can achieve 11% overall performance > boost for SPECvirt than original credit scheduler. Is it possible to publish the raw numbers? > 2. We have tried 1ms delay and 10ms delay, there is no big difference > between these two configurations. (1ms is enough to achieve a good > performance) > 3. We have compared different load level response time/latency (low, > high, peak), "delay method" didn't bring very much response time > increase. > 4. 1ms delay can reduce 30% context switch at peak performance, where > produces the benefits. (.int sched_ratelimit_us = 1000. is the > recommended setting) > > Signed-off-by: Hui Lv <hui.lv@xxxxxxxxx> > Signed-off-by: George Dunlap <George.Dunlap@xxxxxxxxxxxxx> > > diff -r a4bff36780a3 -r 114495d1ff94 xen/common/sched_credit.c > --- a/xen/common/sched_credit.c Fri Dec 16 18:46:27 2011 +0000 > +++ b/xen/common/sched_credit.c Mon Dec 19 15:58:50 2011 -0500 > @@ -110,6 +110,10 @@ boolean_param("sched_credit_default_yiel > static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS; > integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms); > > +/* Scheduler generic parameters > +*/ > +extern int sched_ratelimit_us; If this is generic then it seems like xen/sched.h is the right place for it. Is it really generic though if only the credit scheduler applies it? > + > /* > * Physical CPU > */ > @@ -1297,10 +1301,15 @@ csched_schedule( > struct csched_private *prv = CSCHED_PRIV(ops); > struct csched_vcpu *snext; > struct task_slice ret; > + s_time_t runtime, tslice; > > CSCHED_STAT_CRANK(schedule); > CSCHED_VCPU_CHECK(current); > > + runtime = now - current->runstate.state_entry_time; > + if ( runtime < 0 ) /* Does this ever happen? */ > + runtime = 0; > + > if ( !is_idle_vcpu(scurr->vcpu) ) > { > /* Update credits of a non-idle VCPU. */ > @@ -1313,6 +1322,41 @@ csched_schedule( > scurr->pri = CSCHED_PRI_IDLE; > } > > + /* Choices, choices: > + * - If we have a tasklet, we need to run the idle vcpu no matter what. > + * - If sched rate limiting is in effect, and the current vcpu has > + * run for less than that amount of time, continue the current one, > + * but with a shorter timeslice and return it immediately > + * - Otherwise, chose the one with the highest priority (which may > + * be the one currently running) > + * - If the currently running one is TS_OVER, see if there > + * is a higher priority one waiting on the runqueue of another > + * cpu and steal it. > + */ > + > + /* If we have schedule rate limiting enabled, check to see > + * how long we've run for. */ > + if ( !tasklet_work_scheduled > + && sched_ratelimit_us > + && vcpu_runnable(current) > + && !is_idle_vcpu(current) > + && runtime < MICROSECS(sched_ratelimit_us) ) > + { > + snext = scurr; > + snext->start_time += now; > + perfc_incr(delay_ms); > + tslice = MICROSECS(sched_ratelimit_us); > + ret.migrated = 0; > + goto out; > + } > + else > + { This is the same comment as the next block below, does it really apply here too? Since the previous if block ends with a goto the else clause is a bit redundant. > + /* > + * Select next runnable local VCPU (ie top of local runq) > + */ > + tslice = MILLISECS(prv->tslice_ms); > + } > + > /* > * Select next runnable local VCPU (ie top of local runq) > */ > @@ -1367,11 +1411,12 @@ csched_schedule( > if ( !is_idle_vcpu(snext->vcpu) ) > snext->start_time += now; > > +out: > /* > * Return task to run next... > */ > ret.time = (is_idle_vcpu(snext->vcpu) ? > - -1 : MILLISECS(prv->tslice_ms)); > + -1 : tslice); > ret.task = snext->vcpu; > > CSCHED_VCPU_CHECK(ret.task); > diff -r a4bff36780a3 -r 114495d1ff94 xen/common/schedule.c > --- a/xen/common/schedule.c Fri Dec 16 18:46:27 2011 +0000 > +++ b/xen/common/schedule.c Mon Dec 19 15:58:50 2011 -0500 > @@ -47,6 +47,12 @@ string_param("sched", opt_sched); > bool_t sched_smt_power_savings = 0; > boolean_param("sched_smt_power_savings", sched_smt_power_savings); > > +/* Default scheduling rate limit: 1ms > + * It's not recommended to set this value bigger than > "sched_credit_tslice_ms" > + * otherwise, something weired may happen weird It that constraint enforced anywhere? > + * */ > +int sched_ratelimit_us = 1000; > +integer_param("sched_ratelimit_us", sched_ratelimit_us); > /* Various timer handlers. */ > static void s_timer_fn(void *unused); > static void vcpu_periodic_timer_fn(void *data); > diff -r a4bff36780a3 -r 114495d1ff94 xen/include/xen/perfc_defn.h > --- a/xen/include/xen/perfc_defn.h Fri Dec 16 18:46:27 2011 +0000 > +++ b/xen/include/xen/perfc_defn.h Mon Dec 19 15:58:50 2011 -0500 > @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq, "sch > PERFCOUNTER(sched_run, "sched: runs through scheduler") > PERFCOUNTER(sched_ctx, "sched: context switches") > > +PERFCOUNTER(delay_ms, "csched: delay") > PERFCOUNTER(vcpu_check, "csched: vcpu_check") > PERFCOUNTER(schedule, "csched: schedule") > PERFCOUNTER(acct_run, "csched: acct_run") > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |