Re: credit2 question

[George Dunlap <george.dunlap@eu.citrix.com>]

On 24/01/13 10:06, Jan Beulich wrote:
>>>> On 24.01.13 at 10:49, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> On 24/01/13 07:40, Jan Beulich wrote:
>>> George,
>>>
>>> I'm getting puzzled by the second c2t() invocation in
>>> csched_runtime(): Why is the difference of credits being passed
>>> here? Doesn't that (unless svc->credit is non-positive, i.e. in all
>>> but unusual cases) guarantee time > ntime, and particularly
>>> allow for negative ntime?
>> Ah, right -- yes, if the other guys' credit is positive, "ntime" is
>> guaranteed to be lower.  Since c2t() involves integer division, it would
>> definiteyl be good to get rid of the extra call if we can.
>>
>> My general principle is to make the code clear and easily readable
>> first, and then do optimization afterwards -- in this case I just never
>> came back and did the optimization step.
> Oh, I wasn't thinking of just the optimization. It seemed wrong to
> me to do the subtraction there in the first place: "time" is being
> calculated from a plain value, so why would "ntime" be calculated
> from a delta?

Ah, right -- so the idea here was to run until snext->credit was equal 
to svc->credit.  That's why the delta.

The whole algorithm was supposed to be:
1. At a basic level, run until your credit is 0.
2. But if there's someone else waiting to run, run until your credit ~= 
their credit.
3. But never run shorter than MIN_TIMER  or longer than MAX_TIMER.

#2 is one of the "experimental" / "research-y" ideas I was trying out.  
One of the goals was to reward vcpus that yielded by making sure that 
they would get better latency.

  -George