tags:

views:

740

answers:

1

I've read chapter 7 in the 'Linux Device Drivers' (which can be found here) that time can be measured in 'jiffies'. The problem with the stock jiffies variable is that it wraps around quite frequently (especially if you have your CONFIG_HZ set to 1000).

In my kernel module I'm saving a jiffies value that is set to some time in the future and comparing it at a later time with the current 'jiffies' value. I've learned already that there are functions that take the 32bit jiffy wrap into consideration so to compare two values I'm using this:

if (time_after(jiffies, some_future_jiffies_value))
{
   // we've already passed the saved value
}

Here comes my question: So now I want to set the 'some_future_jiffies_value' to "now + 10ms". This can easily be accomplished by doing this:

some_future_jiffies_value = jiffies + msecs_to_jiffies(10);

Is this correct? What happens if the current jiffies is near MAX_JIFFY_OFFSET and the resulting value of msecs_to_jiffies(10) puts some_future_jiffies_value past that offset? Does it wrap around automatically or should I add some code to check for this? Are there functions that save me from having to deal with this?

Update:

To avoid stuff with wraparound I've rewritten my sleep loop:

   // Sleep for the appropriate time
   while (time_after(some_future_jiffies_value, jiffies))
   {
      set_current_state(TASK_INTERRUPTIBLE);
      schedule_timeout(1);
   }

I assume this is more portable right?

Update 2:

Thank you very much 'ctuffli' for taking the time to come back to this question and providing some feedback on my comments as well. My kernel driver is working fine now and it is a lot less ugly compared to the situation before you provided me with all these tips. Thanks!

+4  A: 

What you are implementing here is essentially msleep_interruptible() (linux/kernel/timer.c)

/**
 * msleep_interruptible - sleep waiting for signals
 * @msecs: Time in milliseconds to sleep for
 */
unsigned long msleep_interruptible(unsigned int msecs)

This function has the advantage that the specification is in milliseconds and hides the details of jiffies wrapping internally. Be sure to check the return values as this call returns the number of jiffies remaining. Zero means the call slept the specified number of milliseconds while a non-zero value indicates the call was interrupted this many jiffies early.

With regard to wrapping, see section 6.2.1.2 for a description of jiffies and wrapping. Also, this post tries to describe wrapping in the abstract.

ctuffli
If I look at the source for msleep_interruptible it looks remarkably similar indeed! I would still have to consider the return value from that function if I understand correctly since the interruptible sleep can return earlier than expected right?
Benjamin
Regarding putting a timeout past MAX_JIFFY_OFFSET mark, do you have any idea if this is OK? I see it happen a lot in the kernel sources but this is a more theoretical thing I was wondering about. Thanks for taking the time to respond so far! :)
Benjamin