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/
This archive was generated by hypermail 2b29 : Mon May 07 2001 - 21:00:16 EST