[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.