Kernel timers and jiffie wrap-around

Kernel timers and jiffie wrap-around

[Jamie]

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().

Note to test the above problem I set jiffies and timer_jiffies in sched.c to a large value and then I had a module loop around adding a timer which prints the current jiffie count and then readds the timer.

There are postings in the archive regarding the general problem of jiffie wrap-around and also of timers with wrap-around. Now most of the posts on jiffie wrap-around suggest that there is now no problem with this but the posts on timers seem to suggest that this is not the case. From memory most of these posts were regarding the 2.1.x series.

The above reasoning is for the 2.2.x series kernels but seems to apply to the 2.4.x-pre series as well since the internal_add_timer() function hasn't changed.

Surely I've misunderstood something in the timer code ? 
Can anyone shed some light on this ?

Thanks for your help,

-jamie.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Kernel timers and jiffie wrap-around

[george anzinger]

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~