Re: [Xen-devel] Question about the credit2 sources in xen-unstable tree.

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

Hmm, I seem not to have documented that bit of code very well. :-)

The idea is this:
1) Start with runtime = amount of time until this vcpu's credit reaches 0:
   time = c2t(rqd, snext->credit, snext);
2) Then, if there's another vcpu on the runqueue, calculate how much
time until the current vcpu's credit matches that vcpu's credit:
   ntime = c2t(rqd, snext->credit - svc->credit, snext);
   if ( time > ntime )
      time = ntime;
3) Finally, never let the time go outside of the minimum and maximum
schedule times:
   if ( time < CSCHED_MIN_TIMER )
      time = CSCHED_MIN_TIMER;
   else if ( time > CSCHED_MAX_TIMER )
      time = CSCHED_MAX_TIMER;

Does that make sense?

So let's say snext has 10 ms of credit, and there's a vcpu on the
runqueue with 5ms of credit.  Then it will be scheduled to run for 2
ms (since right now MAX_TIMER is set to 2ms).  But if the vcpu on the
runqueue has 9ms of credit, it snext will only be allowed to run for
1ms (so that when it finishes, both will have about 9ms of credit).
If, however, the next vcpu on the runqueue has 9.9ms of credit, snext
will be schedule to run for 0.5ms (since MIN_TIMER is set to 500us).

Does that make sense?

I chose MIN_TIMER and MAX_TIMER rather arbitrarily -- they probably
could use some tweaking.

 -George

2011/4/5 peb1611 <peb1611@xxxxxxxxx>:
> Hi, all
>
> I am analyzing the credit2 scheduler in order to adopt to my own private
> cloud, which should satisfy the conditions of some latency sensitive
> applications.
>
> In the latest xen-unstable repository, which is tip tags, I found some
> codes that is not understandable to me.
>
> In the xen/common/sched_credit2.c,
>
> /* How long should we let this vcpu run for? */
> static s_time_t
> csched_runtime(const struct scheduler *ops, int cpu, struct csched_vcpu
> *snext)
> {
> s_time_t time = CSCHED_MAX_TIMER;
> struct csched_runqueue_data *rqd = RQD(ops, cpu);
> struct list_head *runq = &rqd->runq;
>
> if ( is_idle_vcpu(snext->vcpu) )
> return CSCHED_MAX_TIMER;
>
> /* Basic time */
> time = c2t(rqd, snext->credit, snext);
>
> /* Next guy on runqueue */
> if ( ! list_empty(runq) )
> {
> struct csched_vcpu *svc = __runq_elem(runq->next);
> s_time_t ntime;
>
> if ( ! is_idle_vcpu(svc->vcpu) )
> {
> ntime = c2t(rqd, snext->credit - svc->credit, snext);
>
> if ( time > ntime )
> time = ntime;
> }
> }
>
> /* Check limits */
> if ( time < CSCHED_MIN_TIMER )
> time = CSCHED_MIN_TIMER;
> else if ( time > CSCHED_MAX_TIMER )
> time = CSCHED_MAX_TIMER;
>
> return time;
> }
>
> As I understand, this function is used to determining the next vcpu's
> running time-slice from now to the next scheduling event.
>
> So, what does this code mean?
>
> if ( time > ntime )
> time = ntime;
>
> actually, I think it is not different as
>
> if ( svc->credit > 0 )
> time = ntime;
>
> If so, It means that if credits of the next guy on runqueue are not
> negative caculated time-slice is snext's time, or time of the next guy
> is selected and then eventually saturated by the CSCHED_MIN_TIMER.
>
> what is the implication of it?
>
> Am I correct ? If not, would you please kindly let me know about the
> mecahnism of caculating the next-time slice?
>
> Thanks
>
> --
> Eunbyung Park
>
>
> _______________________________________________
> 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