Documentation_timers_timers-howto.txt

Chinese translated version of Documentation_timers_timers-howto

If you have any comment or update to the content, please contact the
original document maintainer directly.  However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help.  Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.

Chinese maintainer:  <1538850747@qq.com>
---------------------------------------------------------------------
Documentation_timers_timers-howto的中文翻译

如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。

中文版维护者： 孙航海  <1538850747@qq.com>
中文版翻译者： 孙航海  <1538850747@qq.com>
中文版校译者： 孙航海  <1538850747@qq.com>

 

 

以下为正文
---------------------------------------------------------------------

delays - Information on the various kernel delay / sleep mechanisms

延迟——信息在不同内核的延迟/睡眠机制
-------------------------------------------------------------------


This document seeks to answer the common question: "What is the
RightWay (TM) to insert a delay?"


这个文档试图回答这个常见的问题:“什么是插入一个延迟的RightWay(TM)?”


This question is most often faced by driver writers who have to
deal with hardware delays and who may not be the most intimately
familiar with the inner workings of the Linux Kernel.


这个问题是处理硬件延误和最熟悉Linux内核的内部运作的驱动程序编写者最
经常面对的。




Inserting Delays


插入延迟
----------------


The first, and most important, question you need to ask is "Is my
code in an atomic context?"  This should be followed closely by "Does
it really need to delay in atomic context?" If so...


第一,也是最重要的,你要问的问题是,“我代码是否在一个atomic环境下?“紧随其
后的是”它是否确实需要延迟在atomic环境下？“如果是这样......


ATOMIC CONTEXT:


You must use the *delay family of functions. These
functions use the jiffie estimation of clock speed
and will busy wait for enough loop cycles to achieve
the desired delay:

你必须使用*延迟函数族。这些函数使用jiffie估计时钟速度
并将忙等待足够的循环周期来实现所需的延迟:


ndelay(unsigned long nsecs)
    udelay(unsigned long usecs)
    mdelay(unsigned long msecs)

ndelay(无符号长的nsecs)
udelay(无符号长的usecs)
mdelay(无符号长的msecs)


udelay is the generally preferred API; ndelay-level
precision may not actually exist on many non-PC devices.

udelay是一般首选的API;ndelay级的精密度实际上在许多非PC设
备上可能是是不存在的。


mdelay is macro wrapper around udelay, to account for
possible overflow when passing large arguments to udelay.
In general, use of mdelay is discouraged and code should
be refactored to allow for the use of msleep.

mdelay是udelay的宏包装,来解释传大参数给udelay可能的溢出。
在一般情况下，使用mdelay是气馁的并且重构代码应该是允许使
用msleep。


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 :)

你应该使用*睡眠[_range]函数族。这里有一些更多的选择，当它
们中的任何一个可以正常工作，使用“right”的睡眠功能将帮助调
度器，电源管理，和让你的驱动器更好：）


-- 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)

-- 通过忙等待循环支持：
udelay(无符号长usecs)
-- 通过hrtimers支持:
usleep_range(无符号长min, 无符号长max)
-- 通过jiffies / legacy_timers支持:
msleep(无符号长msecs)
msleep_interruptible(无符号长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 ( < ~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 "A FEW" USECS ( < ~10us? ):
*使用udelay


-为什么不usleep?
在较慢的系统（嵌入式，或者speed-stepped电脑）为usleep
设立hrtimers的开销可能是不值得的。这种评价显然将取决于
你的具体情况，但它是需要注意的。


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

SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms):
* 使用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.

- 为什么不msleep为了(1ms - 20ms)?
最初解释在这里：
http://lkml.org/lkml/2007/8/3/250
msleep(1~20)可能不会实现调用者的意图，并且往往会睡得更久
(约20毫秒的实际睡眠对于任何值给出的1~20毫秒范围内).在许多
情况下，这不是所期望的行为。


- 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.

- 为什么没有"usleep" /良好的范围是什么？
自从usleep_range建立在hrtimers的顶部，唤醒将是非常精确
的（ISH），因此一个简单的唤醒usleep函数可能会引进大量不
希望的中断。


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.

SLEEPING FOR LARGER MSECS ( 10ms+ )
* 使用msleep或着也许是msleep_interruptible


- 有什么区别？
msleep的设置当前任务TASK_UNINTERRUPTIBLE而msleep_interruptible
在调度睡眠前设置当前任务TASK_INTERRUPTIBLE。简而言之，
不同的是是否可以早点结束睡眠通过一个信号。在一般情况下，
只使用msleep除非你知道你一个可中断的变体。