Chinese translated version of Documentation/virtual/kvm/locking.txt
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: 王明达 530999000@qq.com
---------------------------------------------------------------------
Documentation/virtual/kvm/locking.txt的中文翻译
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。
中文版维护者： 王明达 530999000@qq.com
中文版翻译者： 王明达 530999000@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?"
此文件旨在回答常见的问题：“插入一个延迟的正确方法（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 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:
你必须使用*delay family的函数。这些函数使用jiffie的时钟速度估计来忙于
等待足够的循环以实现所需的延迟：
ndelay(unsigned long nsecs)
udelay(unsigned long usecs)
mdelay(unsigned long msecs)
udelay is the generally preferred API; ndelay-level
precision may not actually exist on many non-PC devices.
udelay是普遍首选的API；ndelay-level精度可能实际上并不存在于许多非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 :)
你应该使用 *sleep[_range] family的函数。这里有更多的选择，当他们其中人一
个都可能正常工作，使用“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)
Unlike the *delay family, the underlying mechanism
driving each of these calls varies, thus there are
quirks you should be aware of.
与*delay family不同，底层机制驱动着不同的调用机制，因此你应该注意这里有
许多问题。
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.
在较慢的系统，（嵌入式，或者一个速度阶梯PC！）usleep设立hrtimers
的开销*可能*不值得的。这样的评价显然将取决于您的具体情况，但要知
道它是什么。
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.
msleep(1~20) 可能完成不了调用者期望做的事情，且可能沉睡得更久（
约20毫秒实际睡眠给出的任何值在1〜20ms的范围）。在许多情况下，这是我
们不希望看到的行为。
- 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——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.
你提供更大的维度，不触发中断的机会就会越大； 这应该与
delay/performance绑定到所能接受的上限与你特定的代码路径相平衡，这里
的精准公差是非常具体的情况，因此他留给调用者来确定一个合理的维度。
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.
msleep 设置当前任务给TASK_UNINTERRUPTIBLE而msleep_inter在调用休眠之
前设置当前任务给TASK_INTERRUPTIBLE。总之，不同之处在于休眠是否可以由
一个信号提前结束。在一般情况下只使用msleep除非你知道有一个需要的中断
转化。
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: 王明达 530999000@qq.com
---------------------------------------------------------------------
Documentation/virtual/kvm/locking.txt的中文翻译
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。
中文版维护者： 王明达 530999000@qq.com
中文版翻译者： 王明达 530999000@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?"
此文件旨在回答常见的问题：“插入一个延迟的正确方法（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 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:
你必须使用*delay family的函数。这些函数使用jiffie的时钟速度估计来忙于
等待足够的循环以实现所需的延迟：
ndelay(unsigned long nsecs)
udelay(unsigned long usecs)
mdelay(unsigned long msecs)
udelay is the generally preferred API; ndelay-level
precision may not actually exist on many non-PC devices.
udelay是普遍首选的API；ndelay-level精度可能实际上并不存在于许多非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 :)
你应该使用 *sleep[_range] family的函数。这里有更多的选择，当他们其中人一
个都可能正常工作，使用“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)
Unlike the *delay family, the underlying mechanism
driving each of these calls varies, thus there are
quirks you should be aware of.
与*delay family不同，底层机制驱动着不同的调用机制，因此你应该注意这里有
许多问题。
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.
在较慢的系统，（嵌入式，或者一个速度阶梯PC！）usleep设立hrtimers
的开销*可能*不值得的。这样的评价显然将取决于您的具体情况，但要知
道它是什么。
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.
msleep(1~20) 可能完成不了调用者期望做的事情，且可能沉睡得更久（
约20毫秒实际睡眠给出的任何值在1〜20ms的范围）。在许多情况下，这是我
们不希望看到的行为。
- 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——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.
你提供更大的维度，不触发中断的机会就会越大； 这应该与
delay/performance绑定到所能接受的上限与你特定的代码路径相平衡，这里
的精准公差是非常具体的情况，因此他留给调用者来确定一个合理的维度。
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.
msleep 设置当前任务给TASK_UNINTERRUPTIBLE而msleep_inter在调用休眠之
前设置当前任务给TASK_INTERRUPTIBLE。总之，不同之处在于休眠是否可以由
一个信号提前结束。在一般情况下只使用msleep除非你知道有一个需要的中断
转化。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
