linux-kernel-driver-dev/sleeping.html at master · txrxlabs/linux-kernel-driver-dev · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
<html>
<font face="helvetica">
<title>Sleeping and delaying</title>
<body>
<p align=center><font size=+5>Sleeping and delaying</font>
<hr>
<a href="contents.html">Contents</a>
<font size=+3>
<hr>
<p>"Did you sleep well?" "No, I made a couple of mistakes." -- Steven Wright
<hr>
<li>Sleeping and Delaying
<p>So you find yourself in a position in which
your code needs to hang out and not doing anything for a little while.
<p>If you are in atomic context (e.g. in an interrupt handler)
then you must first ask yourself "Do I <em>really</em> need to delay
here, or is there some better way to do what I'm trying to do?"
<p>If it turns out that you really do need to delay in atomic context,
then you must use one of the "delay" functions, which busy waits.
<pre>
        ndelay(unsigned long nsecs)
        udelay(unsigned long usecs)
        mdelay(unsgined long msecs)
</pre>
Of these, udelay is preferred, and the putative nano-second precision
of ndelay may not actually be available.
<p>If you are not in atomic context and you need to delay, you want
to use the "sleep" family of functions rather than the "delay" family
of functions.

<p>At this point, I'm just going to quote Documentation/timers/timers-howto.txt:

<pre>
NON-ATOMIC CONTEXT:
	You should use the *sleep[_range] family of functions.
	There are a few more options here, while any of them may
	work correctly, using the "right" sleep function will
	help the scheduler, power management, and just make your
	driver better :)

	-- Backed by busy-wait loop:
		udelay(unsigned long usecs)
	-- Backed by hrtimers:
		usleep_range(unsigned long min, unsigned long max)
	-- Backed by jiffies / legacy_timers
		msleep(unsigned long msecs)
		msleep_interruptible(unsigned long msecs)

	Unlike the *delay family, the underlying mechanism
	driving each of these calls varies, thus there are
	quirks you should be aware of.


	SLEEPING FOR "A FEW" USECS ( &lt; ~10us? ):
		* Use udelay

		- Why not usleep?
			On slower systems, (embedded, OR perhaps a speed-
			stepped PC!) the overhead of setting up the hrtimers
			for usleep *may* not be worth it. Such an evaluation
			will obviously depend on your specific situation, but
			it is something to be aware of.

	SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms):
		* Use usleep_range

		- Why not msleep for (1ms - 20ms)?
			Explained originally here:
				http://lkml.org/lkml/2007/8/3/250
			msleep(1~20) may not do what the caller intends, and
			will often sleep longer (~20 ms actual sleep for any
			value given in the 1~20ms range). In many cases this
			is not the desired behavior.

		- Why is there no "usleep" / What is a good range?
			Since usleep_range is built on top of hrtimers, the
			wakeup will be very precise (ish), thus a simple
			usleep function would likely introduce a large number
			of undesired interrupts.

			With the introduction of a range, the scheduler is
			free to coalesce your wakeup with any other wakeup
			that may have happened for other reasons, or at the
			worst case, fire an interrupt for your upper bound.

			The larger a range you supply, the greater a chance
			that you will not trigger an interrupt; this should
			be balanced with what is an acceptable upper bound on
			delay / performance for your specific code path. Exact
			tolerances here are very situation specific, thus it
			is left to the caller to determine a reasonable range.

	SLEEPING FOR LARGER MSECS ( 10ms+ )
		* Use msleep or possibly msleep_interruptible

		- What's the difference?
			msleep sets the current task to TASK_UNINTERRUPTIBLE
			whereas msleep_interruptible sets the current task to
			TASK_INTERRUPTIBLE before scheduling the sleep. In
			short, the difference is whether the sleep can be ended
			early by a signal. In general, just use msleep unless
			you know you have a need for the interruptible variant.
</pre>

</font>
</body>
</html>