Re: Question about the credit2 sources in xen-unstable tree.

[peb1611 <peb1611@gmail.com>]

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@gmail.com>:
>> 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@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>

-- 
Eunbyung Park