From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [PATCH] credit: track residual from divisions done
 during accounting
Date: Tue, 26 Feb 2013 11:26:10 +0000
Message-ID: <512C9BD2.70903@eu.citrix.com>
References: <51222E8302000078000BF1F3@nat28.tlf.novell.com>
	<1361554003.16232.33.camel@Solace>
	<512B3CF702000078000C0AC6@nat28.tlf.novell.com>
	<512B4724.5000603@citrix.com>
	<512B594E02000078000C0BD1@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <512B594E02000078000C0BD1@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>, David Vrabel <david.vrabel@citrix.com>, xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 02/25/2013 11:30 AM, Jan Beulich wrote:
>>>> On 25.02.13 at 12:12, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 25/02/13 09:29, Jan Beulich wrote:
>>>>>> On 22.02.13 at 18:26, Dario Faggioli <dario.faggioli@citrix.com> wrote:
>>>> On Mon, 2013-02-18 at 12:37 +0000, Jan Beulich wrote:
>>>>> --- a/xen/common/sched_credit.c
>>>>> +++ b/xen/common/sched_credit.c
>>>>>
>>>>> @@ -242,6 +244,7 @@ __runq_remove(struct csched_vcpu *svc)
>>>>>   static void burn_credits(struct csched_vcpu *svc, s_time_t now)
>>>>>   {
>>>>>       s_time_t delta;
>>>>> +    uint64_t val;
>>>>>       unsigned int credits;
>>>>>
>>>>>       /* Assert svc is current */
>>>>> @@ -250,7 +253,10 @@ static void burn_credits(struct csched_v
>>>>>       if ( (delta = now - svc->start_time) <= 0 )
>>>>>           return;
>>>>>
>>>>> -    credits = (delta*CSCHED_CREDITS_PER_MSEC + MILLISECS(1)/2) /
>> MILLISECS(1);
>>>>> +    val = delta * CSCHED_CREDITS_PER_MSEC + svc->residual;
>>>>> +    svc->residual = do_div(val, MILLISECS(1));
>>>>> +    credits = val;
>>>>> +    ASSERT(credits == val);
>>>>
>>>> I may be missing something, but how can the assert ever be false, given
>>>> the assignment right before it?
>>>
>>> val being wider than credit, this checks that there was no truncation.
>>
>> ASSERT(val <= UINT_MAX);
>>
>> Would be clearer.
>
> A matter of taste perhaps...

I have a taste for coders having to keep as little state in their head 
as possible. :-)  Comparing to UINT_MAX prompts the coder specifically 
to think about the size of the variables.

  -George