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  jiffies0      0x7fffff260      0x80000003   (not noticed yet)1      0x8000b01a1      0xffffffe71      0x00000666   (not noticed yet)2      0x0000ee15Calculate 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 operationsand a timer goes off every few days, saving the clock tick fromdoing any 64-bit operations. The fast path stays fast, while procpscan get useful data even after years of uptime.-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at  http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at  http://www.tux.org/lkml/`

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