如何在Linux内核空间中睡眠? [英] How to sleep in the Linux kernel space?
问题描述
我有一个内核线程,该线程在具有FIFO和最高优先级的特定CPU上分配.该线程会不时休眠,但是时间间隔必须尽可能精确.因此,考虑到这一点,在内核空间中最准确的睡眠方式是什么?
I have a kernel thread which is assigned on a specific CPU with FIFO and highest priority. This thread sleeps from time to time but the time interval must be as precise as possible. So with this in mind what would be the most precise way to sleep in the kernel space?
推荐答案
以下是
您应该使用 You should use the 与 Unlike the 这篇关于如何在Linux内核空间中睡眠?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!非原子上下文:
*sleep[_range]
系列功能.
这里还有更多选择,而其中任何一个都可能
正常工作,使用正确的"睡眠功能将
帮助调度程序,电源管理,并使您的
驱动程序更好:)
NON-ATOMIC CONTEXT:
*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 :)
udelay(unsigned long usecs)
usleep_range(unsigned long min, unsigned long max)
msleep(unsigned long msecs)
msleep_interruptible(unsigned long msecs)
udelay(unsigned long usecs)
usleep_range(unsigned long min, unsigned long max)
msleep(unsigned long msecs)
msleep_interruptible(unsigned long msecs)
*delay
系列不同,其潜在机制
这些呼叫的驱动方式各不相同,因此有
您应该注意的怪癖.*delay
family, the underlying mechanism
driving each of these calls varies, thus there are
quirks you should be aware of.
udelay
usleep
?
在较慢的系统上,(嵌入式,或者可能是速度步进
PC!)设置hrtimers的开销
因为usleep
可能不值得.这样的评价
显然将取决于您的具体情况,但是
这是需要注意的事情.
udelay
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.
usleep_range
msleep
持续(1ms-20ms)?
最初在这里解释:
http://lkml.org/lkml/2007/8/3/250
msleep
(1〜20)可能无法满足呼叫者的意图,并且
通常会睡得更长一些(任何睡眠时间约20毫秒,
值在1〜20ms范围内).在许多情况下
不是期望的行为.
usleep
/什么是好的范围?
由于usleep_range
是基于hrtimers构建的,因此
唤醒将非常精确(ish),因此简单
usleep
函数可能会引入大量
意外中断.
随着范围的引入,调度程序是
可以自由地将您的唤醒与其他任何唤醒
可能是由于其他原因而发生的,或在
最坏的情况是为您的上限触发中断.
您提供的范围越大,机会就越大
您不会触发中断;这应该
与可接受的上限保持平衡
特定代码路径的延迟/性能.精确的
这里的公差是非常具体的情况,因此
留给呼叫者确定合理的范围.
usleep_range
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.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.
msleep
或可能的msleep_interruptible
msleep
将当前任务设置为TASK_UNINTERRUPTIBLE
而msleep_interruptible
将当前任务设置为
TASK_INTERRUPTIBLE
在安排睡眠之前.在
简而言之,区别在于睡眠是否可以结束
提前发出信号.通常,除非使用msleep
,否则
您知道您需要可中断的变体.
msleep
or possibly msleep_interruptible
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.