lkml.org 
[lkml]   [2011]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 3.1-rc9
On 10/17/2011 02:19 PM, Ingo Molnar wrote:
>
> it's 64/32 division - it's the /1000000000 /1000000 /1000 divisions
> in the large majority of cases, to convert between
> seconds/milliseconds/microseconds and scalar nanoseconds.
>
> the kernel-internal ktime_t in the 32-bit optimized case is:
>
> union ktime {
> s32 sec, nsec;
> };
>
> which is the same as timespec and arithmetically close to timeval,
> which many ABIs use. So conversion is easy in that case - but
> arithmetics gets a bit harder.
>
> If we used a scalar 64-bit form for all kernel internal time
> representations:
>
> s64 nsecs;
>
> then conversions back to timespec/timeval would involve dividing this
> 64-bit value with 1000000000 or 1000000.
>
> Is there no faster approximation for those than bit by bit?
>
> In particular we could try something like:
>
> (high*2^32 + low)/1e9 ~== ( high * (2^64/1e9) ) / 2^32
>
> ... which reduces it all to a 64-bit multiplication (or two 32-bit
> multiplications) with a known constant, at the cost of 1 nsec
> imprecision of the result - but that's an OK approximation in my
> opinion.
>

We can do much better than that with reciprocal multiplication. We're
already playing reciprocal multiplication tricks for jiffies conversion,
and in this case it's much easier because the constant is already known.

-hpa



\
 
 \ /
  Last update: 2011-10-17 23:25    [W:1.463 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site