Thanks for your very kind explanation :-)
Now, I'm totally make sense of what the code would say and I'm sorry
about asking you withoug thoughtful consideration.
and then, I hope that the credit2 works well for not only latency
sensitive apps but also any other apps.
Thank you once again.
2011-04-05 오후 6:12, George Dunlap 쓴 글:
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
--
Eunbyung Park
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home