Messages in this thread |  | | Date | Wed, 2 May 2001 16:47:21 +0900 (JST) | From | Tom Holroyd <> | Subject | Re: Unknown HZ value! (2000) Assume 1024. |
| |
On Wed, 2 May 2001, Albert D. Cahalan wrote:
> This is pretty bogus. The idle time can run _backwards_ on an SMP > system.
True, but it's failing for single CPU systems (like mine), too.
>> I notice also that since kstat.per_cpu_nice is an unsigned int, it's >> going to overflow in another 3.6 days anyhow. ... Any chance of making >> those guys longs?
> For 32-bit systems, we use 32-bit values to reduce overhead. > This causes problems at 495/smp_num_cpus days of uptime.
You mean for HZ == 100. And I guess the overhead in question is the cost of a 64 bit add vs. a 32 bit add HZ times per second? On a 64 bit machine, that overhead is likely to be exactly zero. It is zero on my machine. For integer math on an Alpha, changing the ints to longs can even make a program run faster.
> Proposed hack: set a very-long-duration timer (several days) > to check for the high bit changing. Count bit flips.
What about the interval between when it flips and when you notice it?
No, change the kstat variables to unsigned longs on 64 bit systems. In fact, make them unsigned longs on any system, as opposed to something like u_int64 or whatever. (And fix the code in proc_misc.c that uses them.)
For 32 bit systems with HZ == 1024, decide if an overhead of about 1 usec per second is too much to justify using 64 bits. That's 4 seconds lost over the 49 days it takes to fail (if your hardware isn't that fast what are you doing with HZ == 1024 in the first place).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |