1 .. SPDX-License-Identifier: GPL-2.0
3 Delay and sleep mechanisms
4 ==========================
6 This document seeks to answer the common question: "What is the
7 RightWay (TM) to insert a delay?"
9 This question is most often faced by driver writers who have to
10 deal with hardware delays and who may not be the most intimately
11 familiar with the inner workings of the Linux Kernel.
13 The following table gives a rough overview about the existing function
14 'families' and their limitations. This overview table does not replace the
15 reading of the function description before usage!
18 :widths: 20 20 20 20 20
29 - timer list timers based
31 * - Usage in atomic Context
36 * - precise on "short intervals"
41 * - precise on "long intervals"
46 * - interruptible variant
52 A generic advice for non atomic contexts could be:
54 #. Use `fsleep()` whenever unsure (as it combines all the advantages of the
56 #. Use `*sleep()` whenever possible
57 #. Use `usleep_range*()` whenever accuracy of `*sleep()` is not sufficient
58 #. Use `*delay()` for very, very short delays
60 Find some more detailed information about the function 'families' in the next
63 `*delay()` family of functions
64 ------------------------------
66 These functions use the jiffy estimation of clock speed and will busy wait for
67 enough loop cycles to achieve the desired delay. udelay() is the basic
68 implementation and ndelay() as well as mdelay() are variants.
70 These functions are mainly used to add a delay in atomic context. Please make
71 sure to ask yourself before adding a delay in atomic context: Is this really
74 .. kernel-doc:: include/asm-generic/delay.h
75 :identifiers: udelay ndelay
77 .. kernel-doc:: include/linux/delay.h
81 `usleep_range*()` and `*sleep()` family of functions
82 ----------------------------------------------------
84 These functions use hrtimers or timer list timers to provide the requested
85 sleeping duration. In order to decide which function is the right one to use,
86 take some basic information into account:
88 #. hrtimers are more expensive as they are using an rb-tree (instead of hashing)
89 #. hrtimers are more expensive when the requested sleeping duration is the first
90 timer which means real hardware has to be programmed
91 #. timer list timers always provide some sort of slack as they are jiffy based
93 The generic advice is repeated here:
95 #. Use `fsleep()` whenever unsure (as it combines all the advantages of the
97 #. Use `*sleep()` whenever possible
98 #. Use `usleep_range*()` whenever accuracy of `*sleep()` is not sufficient
100 First check fsleep() function description and to learn more about accuracy,
101 please check msleep() function description.
107 .. kernel-doc:: include/linux/delay.h
108 :identifiers: usleep_range usleep_range_idle
110 .. kernel-doc:: kernel/time/sleep_timeout.c
111 :identifiers: usleep_range_state
117 .. kernel-doc:: kernel/time/sleep_timeout.c
118 :identifiers: msleep msleep_interruptible
120 .. kernel-doc:: include/linux/delay.h
121 :identifiers: ssleep fsleep