Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: Unknown HZ value! (2000) Assume 1024. | Date | Thu, 3 May 2001 02:15:20 -0400 (EDT) |
| |
Tom Holroyd writes: > On Wed, 2 May 2001, Albert D. Cahalan wrote:
>> 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.
Well, OK. No unmodified 32-bit system runs HZ == 1024.
> 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.
Yes.
>> 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?
Not a problem. Note that I count bit flips, not roll overs. Here are the two variables, with "flips" lagging a bit:
flips jiffies 0 0x7fffff26 0 0x80000003 (not noticed yet) 1 0x8000b01a 1 0xffffffe7 1 0x00000666 (not noticed yet) 2 0x0000ee15
Calculate 64-bit (well, 63-bit) jiffies as:
long long total; unsigned f = flips; unsigned j = jiffies; f += (f ^ (j>>31)) & 1; total = ((long long)f<<31) | j;
Now print the total.
Well, there it is. Like it? The /proc reader does 64-bit operations and a timer goes off every few days, saving the clock tick from doing any 64-bit operations. The fast path stays fast, while procps can get useful data even after years of uptime.
- 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/
| |