^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ===================================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) delays - Information on the various kernel delay / sleep mechanisms
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ===================================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) This document seeks to answer the common question: "What is the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) RightWay (TM) to insert a delay?"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) This question is most often faced by driver writers who have to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) deal with hardware delays and who may not be the most intimately
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) familiar with the inner workings of the Linux Kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) Inserting Delays
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) ----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) The first, and most important, question you need to ask is "Is my
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) code in an atomic context?" This should be followed closely by "Does
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) it really need to delay in atomic context?" If so...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) ATOMIC CONTEXT:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) You must use the `*delay` family of functions. These
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) functions use the jiffie estimation of clock speed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) and will busy wait for enough loop cycles to achieve
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) the desired delay:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) ndelay(unsigned long nsecs)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) udelay(unsigned long usecs)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) mdelay(unsigned long msecs)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) udelay is the generally preferred API; ndelay-level
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) precision may not actually exist on many non-PC devices.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) mdelay is macro wrapper around udelay, to account for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) possible overflow when passing large arguments to udelay.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) In general, use of mdelay is discouraged and code should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) be refactored to allow for the use of msleep.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) NON-ATOMIC CONTEXT:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) You should use the `*sleep[_range]` family of functions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) There are a few more options here, while any of them may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) work correctly, using the "right" sleep function will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) help the scheduler, power management, and just make your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) driver better :)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) -- Backed by busy-wait loop:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) udelay(unsigned long usecs)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) -- Backed by hrtimers:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) usleep_range(unsigned long min, unsigned long max)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) -- Backed by jiffies / legacy_timers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) msleep(unsigned long msecs)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) msleep_interruptible(unsigned long msecs)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) Unlike the `*delay` family, the underlying mechanism
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) driving each of these calls varies, thus there are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) quirks you should be aware of.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) SLEEPING FOR "A FEW" USECS ( < ~10us? ):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) * Use udelay
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) - Why not usleep?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) On slower systems, (embedded, OR perhaps a speed-
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) stepped PC!) the overhead of setting up the hrtimers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) for usleep *may* not be worth it. Such an evaluation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) will obviously depend on your specific situation, but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) it is something to be aware of.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) * Use usleep_range
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) - Why not msleep for (1ms - 20ms)?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) Explained originally here:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) http://lkml.org/lkml/2007/8/3/250
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) msleep(1~20) may not do what the caller intends, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) will often sleep longer (~20 ms actual sleep for any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) value given in the 1~20ms range). In many cases this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) is not the desired behavior.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) - Why is there no "usleep" / What is a good range?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) Since usleep_range is built on top of hrtimers, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) wakeup will be very precise (ish), thus a simple
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) usleep function would likely introduce a large number
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) of undesired interrupts.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) With the introduction of a range, the scheduler is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) free to coalesce your wakeup with any other wakeup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) that may have happened for other reasons, or at the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) worst case, fire an interrupt for your upper bound.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) The larger a range you supply, the greater a chance
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) that you will not trigger an interrupt; this should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) be balanced with what is an acceptable upper bound on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) delay / performance for your specific code path. Exact
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) tolerances here are very situation specific, thus it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) is left to the caller to determine a reasonable range.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) SLEEPING FOR LARGER MSECS ( 10ms+ )
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) * Use msleep or possibly msleep_interruptible
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) - What's the difference?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) msleep sets the current task to TASK_UNINTERRUPTIBLE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) whereas msleep_interruptible sets the current task to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) TASK_INTERRUPTIBLE before scheduling the sleep. In
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) short, the difference is whether the sleep can be ended
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) early by a signal. In general, just use msleep unless
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) you know you have a need for the interruptible variant.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) FLEXIBLE SLEEPING (any delay, uninterruptible)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) * Use fsleep
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags
| Donate