Hello Everyone,

In kernel documentation, it is mentioned that for inserting delay between 0-20 ms, usleep_range should be used and for delays greater than 10 ms, msleep should be used.
Ref Link: https://www.kernel.org/doc/Documenta...mers-howto.txt

Considering HZ to be 100.
In my opinion, for 33 ms delay, msleep would sleep for 40 ms as it backed by jiffies timer and usleep_range would sleep exactly for 33 ms as it is backed by hrtimers.
And for case of 40 ms both msleep and usleep_range would sleep for 40 ms.
Right ?

So if we use use usleep_range for inserting delays greater than 20 ms,
would it be harmful or beneficial or does not make any difference ?

Thanks !

So jiffies in my kernel are 1 msec.

1 members found this post helpful.

So for systems with HZ=1000,
would msleep(40) and sleep_range(40000, 41000) perform same in terms of cpu usage, power usage and accuracy ?

In case of usleep_range, process will wake definitely after max limit.
But I do not know implementation of msleep, will msleep(40) definitely wakes after 41 ms or
it is possible that it wakes process after 45, 50, 60 or 100 ms or more ?

You can, and should, look at the actual implementation in kernel sources.

Linux is not a "real time" kernel. It does not promise to respond within a fixed amount of time. If you delay a process for 40ms or what-have-you, Linux says that it will not wake up sooner, but does not promise that it will wake up on time.

Your only alternative for shorter delays is to, literally, "waste the CPU's time." (Which is never what you want to do.)

Part of the reason for the indeterminacy is that other activity will cause paging out of the idle/sleeping process, thus the wakeup time can get longer due to having to load pages for process.

The short sleep avoids paging, but the long sleep permits it (at least that was how it used to work).

Thanks for the above two inputs!
However, the main concern is the difference between msleep and usleep_range in waking up a process.
As I know, usleep_range can fire an interrupt to achieve accuracy but now with high speed cpu, it does not seem to be a problem.
So is there any case in which usleep_range can actually be considered harmful over msleep ?
Is yes, kindly help to explain the case in detail.

Yes: When/if it deadlocks the system.

The system must be able to page out idle pages. If (as I believe) the usleep blocks paging (it is supposed to be a SHORT sleep) for long periods the system could deadlock. I say "could", not "will".

For a dedicated system, this really doesn't matter.

And there is a realtime Linux configuration: http://www.osadl.org/Realtime-Linux....e-linux.0.html

You do have to configure the kernel for it.

Well, it does not seem that usleep_range blocks paging.
Could you please provide some more details on it which confirms it ?

as of kernel 2.6http://lwn.net/Articles/398846/)
since it is uninterruptable it locks the process (in kernel processing) such that it cannot be interrupted (ALL signals blocked, including -9)... and any associated pages are locked in memory (I/O locks now). Normally this state is short - and the system can perform other activity later. But too many processes in this state (for too long) could deadlock (well, I think the situation would be called a "livelock") the system, and that would include paging (the system may start thrashing).

Since signals are blocked (which includes OOM aborts) you can't release resources.

This is identified as a "D state" for kernel processing.

usleep_range is really designed for short sleeps - longer than "spin on flag" delays, but not in the range of msleep. As I interpret the timers (reference below), only recommended for below 20ms. There is a bit of overlap - but more options for msleep.

https://www.kernel.org/doc/Documenta...mers-howto.txt

The section on "SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms)" and "SLEEPING FOR LARGER MSECS ( 10ms+ )" may help.

It is possible I overstated the paging restriction - looking at the data it may only be restricted to the pages associated with the I/O where the usleep_range is being handled. Of course, if the application is paged out, don't expect response rates below the paging IO rate (which will be much longer and indeterminate). That doesn't prevent you from locking memory to minimize the impact - but that also increases the chance of other problems.

2 members found this post helpful.

Thanks for the detailed explanation!
However, msleep also runs in TASK_UNINTERRUPTIBLE state.
So, D-state problem has a equal chance to happen in both msleep and usleep_range.

No, You can use msleep_interruptible, which is interruptable.

msleep_interruptible runs in TASK_INTERRUPTIBLE but it has its other problems.
Anyways, main concern here is difference between "msleep" and "usleep_range" for large delays.

Aniroop, you've been told the answer half-a-dozen times. Stop bringing up the same question, and instead, listen to what you have been told!

Obviously, you are correct. You should use usleep for all of your sleep purposes: obviously it was a silly mistake for the kernel authors to have written two of them, when both of them "sleep." Go ahead and write your code exactly like that, then come back in a month or so and ask us politely "why your system keeps locking up."

I suspect that, fundamentally, you do not yet understand how "multitasking" actually works. When "a process or thread 'goes to sleep,'" you don't yet understand what happens ... or why ... or "what happens in the meantime, until the process/thread once again 'wakes up.'" Or, why there is then an indeterminate delay between "the moment that it 'wakes up'" and "the moment that it 'executes again.'"

If you do not fully understand these concepts (yet), then you will not understand what is the difference between these two sleep-functions.

See also: "busy waiting".

Well, the above points are true for both msleep and usleep_range.
And I did not find out any disadvantage as such.

Actually, the real question is how precise must your delay be?

If the delay can be imprecise then using msleep() is the right way because
that lets the kernel batch timers for power saving purposes.

If the delay needs to be precise within the min/max sleep time limits, then
usleep_range() is the way to go. The @delta argument gives the kernel the freedom
to schedule the actual wakeup to a time that is both power and performance friendly.

I suggest that you should never rely upon a delay to be "precise." It should only be "not less than" the requested amount of time.