Jamie wrote:
> 
> Hi !
> 
> I've been trying to determine the reliability of kernel timers when a box has been up for a while. Now as everyone is aware (for HZ=100 (default)), when the uptime of the kernel reaches (approx.) 1.3 years the clock tick count (jiffies) wraps-around. Now if a kernel timer is added just before the wrap-around then from the source I get the impression the kernel timer will be run immediately instead of after the specified delay. Here's my reasoning:
> 
> When adding a timer the internal_add_timer() function is (eventually) called. Given that the current jiffies is close to maximum for an unsigned long value then the following index value is computed:
> 
>         // jiffies = ULONG_MAX - 10, say.
>         // so timer_jiffies is close to jiffies.
>         // timer.expires = jiffies + TIMEOUT_VALUE, where TIMEOUT_VALUE=200, say.
> 
>         index = expires - timer_jiffies;
> 
> Thus index is a large negative number resulting in the timer being added to tv1.vec[tv1.index] which means that the timer is run on the next execution of run_timer_list().

Now just how did you arrive at this?  What value _is_ ULONG_MAX+190?  It
rolls over to 190.  But you should think of timer_jiffies as 0-10 (in
your case) so index=190+10 or the desired 200.  No need to tweak the
kernel, just try some simple C code.  It all works until the requested
time out is greater than ULONG_MAX/2 (about .68 years).

George

   snip~
> 
> Surely I've misunderstood something in the timer code ?

Now you have a good interview question for that next potential new hire
:)

snip~
-
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/