qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 08/10] Count nanoseconds with uint64_t not doubl


From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH 08/10] Count nanoseconds with uint64_t not doubles
Date: Tue, 30 Nov 2010 15:40:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Anthony Liguori <address@hidden> wrote:
> On 11/23/2010 05:03 PM, Juan Quintela wrote:
>> From: Juan Quintela<address@hidden>
>>
>> Signed-off-by: Juan Quintela<address@hidden>
>> Signed-off-by: Juan Quintela<address@hidden>
>>    
>
> Why?

I needed the precision for the timestamp.  Nanoseconds is an "integer"
property, not a float value.  And ferther more, until last line, we are
using a variable named "bwidth" to measure times.

Later, Juan.

> Regards,
>
> Anthony Liguori
>
>> ---
>>   arch_init.c |    7 ++++---
>>   1 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch_init.c b/arch_init.c
>> index 9e941a0..d32aaae 100644
>> --- a/arch_init.c
>> +++ b/arch_init.c
>> @@ -216,6 +216,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
>> void *opaque)
>>   {
>>       ram_addr_t addr;
>>       uint64_t bytes_transferred_last;
>> +    uint64_t t0;
>>       double bwidth = 0;
>>
>>       if (stage<  0) {
>> @@ -258,7 +259,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
>> void *opaque)
>>       }
>>
>>       bytes_transferred_last = bytes_transferred;
>> -    bwidth = qemu_get_clock_ns(rt_clock);
>> +    t0 = qemu_get_clock_ns(rt_clock);
>>
>>       while (!qemu_file_rate_limit(f)) {
>>           int bytes_sent;
>> @@ -270,8 +271,8 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
>> void *opaque)
>>           }
>>       }
>>
>> -    bwidth = qemu_get_clock_ns(rt_clock) - bwidth;
>> -    bwidth = (bytes_transferred - bytes_transferred_last) / bwidth;
>> +    t0 = qemu_get_clock_ns(rt_clock) - t0;
>> +    bwidth = (bytes_transferred - bytes_transferred_last) / t0;
>>
>>       /* if we haven't transferred anything this round, force expected_time 
>> to a
>>        * a very high value, but without crashing */
>>    



reply via email to

[Prev in Thread] Current Thread [Next in Thread]