From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: credit2 question Date: Thu, 24 Jan 2013 09:53:52 +0000 Message-ID: <510104B0.30500@eu.citrix.com> References: <5100F37702000078000B8FC2@nat28.tlf.novell.com> <5101039E.4060504@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5101039E.4060504@eu.citrix.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 09: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. > > Were you intending to submit a patch for this, or shall I? If we're doing optimization, we can probably get away with doing all of the calculation in "credit" (including the MIN/MAX checking), and then only do the conversion if we're not at one of those set points. That should get rid of any integer division entirely in a large number of cases. -George