From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: credit2 question Date: Thu, 24 Jan 2013 10:07:35 +0000 Message-ID: <510107E7.7050701@eu.citrix.com> References: <5100F37702000078000B8FC2@nat28.tlf.novell.com> <5101039E.4060504@eu.citrix.com> <5101159F02000078000B90DC@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5101159F02000078000B90DC@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 24/01/13 10:06, Jan Beulich wrote: >>>> On 24.01.13 at 10:49, George Dunlap 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