On Tue, Oct 30, 2007 at 11:25:55AM +0900, Hidetoshi Seto wrote: > Simon Horman wrote: > > On Tue, Oct 16, 2007 at 10:35:52PM +0900, Hidetoshi Seto wrote: > >> +#define cputime_to_jiffies(__ct) ((__ct) * HZ / NSEC_PER_SEC) > >> +#define jiffies_to_cputime(__jif) ((__jif) * NSEC_PER_SEC / HZ) > >> +#define cputime64_to_jiffies64(__ct) ((__ct) * HZ / NSEC_PER_SEC) > >> +#define jiffies64_to_cputime64(__jif) ((__jif) * NSEC_PER_SEC / HZ) > > > > It looks like cputime64_to_jiffies64 and cputime_to_jiffies will > > overflow at (((2^64 -1) / HZ) + 1) ns. In the case where HZ is 1000, > > this means it will overflow at (584/1000) years or about 213 days. > > Similarly for cputime_to_clock_t(). Is this a problem? > > Exactly. > I guess NSEC_PER_SEC is permanently 10^9, and larger HZ will not be > required soon in this century. Does the following help us? > > #define cputime64_to_jiffies64(__ct) ((__ct) / (NSEC_PER_SEC / HZ)) > #define jiffies64_to_cputime64(__jif) ((__jif) * (NSEC_PER_SEC / HZ)) That does seem to be a lot better. I guess there might be some rounding strangeness if NSEC_PER_SEC is not an integer multiple of HZ, but as both cputime64_to_jiffies64() and jiffies64_to_cputime64() use the same rounded value, this shouldn't be a problem. Actually its probably not a problem at all. I guess there is also now an assumption that HZ is much less than NSEC_PER_SEC, that also seems reasonable. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|