Reliability of Linux kernel add_timer at resolution of one jiffy?

Question

In the code given below, there is a simple Linux kernel module (driver) which calls a function repeatedly 10 times, using add_timer at resolution of 1 jiffy (th

Answer 1

It is indeed possible that your timer function gets called at a later jiffy than what expires what set to. Possible reasons are scheduling delays, other drivers that disable interrupts for too long (graphics and WLAN drivers are usual culprits), or some crappy BIOS executing SMI code.

If you want to avoid that one late timer function shifts all following timer calls, you have to schedule the respective next timer not relative to the current time (jiffies), but relative to the scheduled time of the last timer (my_timer.expires). Alternatively, use ten timers that you all schedule at the beginning at jiffies + 1, 2, 3, …

The timestamp in the log is the time when that string was printed to the log.

Your module is buggy: you must ensure that the timer is not pending before the module is unloaded.