Re: [Xen-devel] the logic of burn_credits

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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