Re: [Xen-devel] credit2 question

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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:
> > > 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel