[lkml]   [2001]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Unknown HZ value! (2000) Assume 1024.
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.


>> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:0.075 / U:0.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site