[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] the logic of burn_credits
On Sun, Apr 13, 2014 at 9:24 AM, he qiang <qiang20102697@xxxxxxxxx> wrote: > I am a undergraduate student and I am reading xen source code. > I can't understand the logic of the function burn_credits in > xen-4.3.2/xen/common/sched_credit.c. > I think the unit of the variable delta is nanosecond and the unit of the > const CSCHED_CREDITS_PER_MSEC is millisecond, > then where is the sense of the line "val = delta * CSCHED_CREDITS_PER_MSEC > + svc->residual;"? (delta / MILLISECS(1)) * CREDITS_PER_MSEC is algebraically equivalent to (delta * CREDITS_PER_MSEC) / MILLISECS(1). But we're not working with real numbers, we're working with integers; doing the first would mean that all times under 1ms get accounted as zero. Doing it the second way allows us to keep around a "remainder", such that eventually the sub-credit runtimes should add up to one credit. > and what does the variable svc->start_time mean? if it means time When the > vcpu was scheduled in system time > and where is the sense of the line "svc->start_time += (credits * > MILLISECS(1)) / CSCHED_CREDITS_PER_MSEC;"? > thank you very much. Hmm. Well the sense of that oridinally was actually, AFAICT, to keep the remainder... by only incrementing your "start clock" according to the credits you were actually charged, eventually sub-credit runtimes should add up to one credit. Which calls into question why c/s cf0c29d was necessary in the first place. Jan, am I missing something here? -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |