That is when it rolls over. What I am talking about is when the compare
of two unsigned numbers gives the wrong answer. That happens when the
difference is greater than 1/2 of the max count. This is independent of
the actual values so it really doesn't matter what the counts are, just
the differences to be compared. The kernel code is very careful to do
the compare in such a way as to avoid the issues around the actual size,
but the max difference of 1/2 the value is another matter and can not be
avoided with out extra bits.
This is important as the add_timer code checks to see if the time has
passed yet. If so it queues the timer for the next tick. This will
happen when the timer is to expire more than 1/2 the max unsigned int
> (On PPC "HZ" is 1024, but i think there "jiffies" is 64-bit.)
> I encountered this problem as my "/proc/uptime"-counter got over the
> ridge and the machine now has an uptime of 550 days, but /proc/uptime
> speaks of 550-497=53 days.
> I also postet a patch against this effect, but this does only cosmetic
> and no major changes to other things like "jiffies".
> If you move HZ to 1000, this moves to 24.855 days, and the
> > 10,000 you want moves it to 2.4855 days which will give problems with at
> > least the cron sub system and probably a lot of others.
> The rollover at my machine (2.2.10) did not do any harm, but that does
> not mean that there will be no negative side-effect.
> Frank Schneider, <SPATZ1@T-ONLINE.DE>.
> Microsoft isn't the answer.
> Microsoft is the question, and the answer is NO.
> ... -.-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/