Re: [Xen-devel] [PATCH v2] xen/credit scheduler; Use delay to control scheduling frequency

["Lv, Hui" <hui.lv@xxxxxxxxx>]

> > +    /* If we have schedule rate limiting enabled, check to see
> > +     * how long we've run for. */
> > +    if ( sched_ratelimit_us
> > +         && !tasklet_work_scheduled
> 
> How about making the checking order match the description above (which
> might also be slightly faster given that tasklet_work_scheduled is a function
> parameter [in a register or written recently], and [given the default value
> you're picking] you expect sched_ratelimit_us to be non-zero generally)?
> 
Thanks, agree this.

> > +         && 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);
> 
> So if there happens to be a VM with
> 
> MILLISECS(prv->tslice_ms) < MICROSECS(sched_ratelimit_us)
> 
> it'd get *more* time than allowed/intended through this mechanism.

First, it does not make sense to set prv->tslice_ms < sched_ratelimit_us. If 
people really need an extreme smaller time slice(1ms, for example), remember to 
set sched_ratelimit_us smaller than prv->tslice_ms or zero.
If people forgot to do so, I think sched_ratelimit_us is higher priority to be 
considered (instead of minimum of both), although this is not the "right"xe 
configuration.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel