[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] credit2 question

On 24/01/13 10:06, Jan Beulich wrote:
On 24.01.13 at 10:49, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
On 24/01/13 07:40, Jan Beulich wrote:

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.