Chinese translated version of Documentation/block/deadline-iosched
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: 799942107@qq.com
---------------------------------------------------------------------
Documentation/block/deadline-iosched的中文翻译
如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文
交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题,请联系中文版维护者。
中文版维护者: 黄佳露 799942107@qq.com
中文版翻译者: 黄佳露 799942107@qq.com
中文版校译者: 潘丽卡 774945605@qq.com
以下为正文
---------------------------------------------------------------------
Deadline IO scheduler tunables
期限IO调度器可调项
==============================
This little file attempts to document how the deadline io scheduler works.
In particular, it will clarify the meaning of the exposed tunables that may be
of interest to power users.
这个小文件试图用文件证明期限IO调度是如何工作的。
特别是,它想澄清可能会暴露于电力用户的可调函数的意义。
Selecting IO schedulers
选择IO调度器
-----------------------
Refer to Documentation/block/switching-sched.txt for information on
selecting an io scheduler on a per-device basis.
参考Documentation/block/switching-sched.txt的信息,用以在每一种设备基础
上选择一个IO调度程序。
********************************************************************************
read_expire (in ms)
读过期(毫秒)
-----------
The goal of the deadline io scheduler is to attempt to guarantee a start
service time for a request. As we focus mainly on read latencies, this is
tunable. When a read request first enters the io scheduler, it is assigned
a deadline that is the current time + the read_expire value in units of
milliseconds.
期限IO调度的目的是为了保证每个请求有一个开始服务时间。我们主要集中在阅读延迟,
这是可调的。当一个读请求第一次进入IO调度程序,它会被分配一个最后期限,这个期限
指的是当前时间+在单位毫秒内读到的期值。
write_expire (in ms)
写到期(毫秒)
-----------
Similar to read_expire mentioned above, but for writes.
类似于上面提到的读到期,但是这是对于写的。
fifo_batch (number of requests)
先进先出批(数量的请求)
----------
Requests are grouped into ``batches'' of a particular data direction (read or
write) which are serviced in increasing sector order. To limit extra seeking,
deadline expiries are only checked between batches. fifo_batch controls the
maximum number of requests per batch.
请求被分成特定的数据方向(读或写)的“批”,可以提高服务质量。为了限制额外的寻求,
期限到期只检查批次之间。 fifo_batch控制每一批的最大请求数。
This parameter tunes the balance between per-request latency and aggregate
throughput. When low latency is the primary concern, smaller is better (where
a value of 1 yields first-come first-served behaviour). Increasing fifo_batch
generally improves throughput, at the cost of latency variation.
这个参数协调每次请求的平衡延迟和聚合吞吐量之间的平衡。当低延迟作为主要的关注对象时,
越小越好(值为1时最小,也就是先到先得)。增加fifo_batch通常可以在延迟变化的成本上
提高吞吐量。
writes_starved (number of dispatches)
写挨饿(数量的派遣)
--------------
When we have to move requests from the io scheduler queue to the block
device dispatch queue, we always give a preference to reads. However, we
don't want to starve writes indefinitely either. So writes_starved controls
how many times we give preference to reads over writes. When that has been
done writes_starved number of times, we dispatch some writes based on the
same criteria as reads.
当我们不得不从IO调度的请求队列移动到块设备调度队列,我们总是给一个优先读取。
但是我们不想要无限期的没东西写。所以写挨饿控制着有多少次我们的优先读取超过了
写数据。当有了一定次数的写挨饿,我们会派遣一些写操作,这些写和读取有着相同的标准。
front_merges (bool)
前合并(bool)
------------
Sometimes it happens that a request enters the io scheduler that is contiguous
with a request that is already on the queue. Either it fits in the back of that
request, or it fits at the front. That is called either a back merge candidate
or a front merge candidate. Due to the way files are typically laid out,
back merges are much more common than front merges. For some work loads, you
may even know that it is a waste of time to spend any time attempting to
front merge requests. Setting front_merges to 0 disables this functionality.
Front merges may still occur due to the cached last_merge hint, but since
that comes at basically 0 cost we leave that on. We simply disable the
rbtree front sector lookup when the io scheduler merge function is called.
有时候,当一个请求进入IO调度,而且是连续的,已经在队列中的请求,会发生前合并。
前合并要么适合在请求的后面,要么适合在前面。这叫做后合并的候选或者是前合并的候选。
由于文件典型的布局,后合并通常比前合并更为普遍使用。对于一些工作负载,你甚至可能
知道它在前合并请求尝试中是浪费时间。设置前合并为0来禁用此功能。前合并仍然有可能
会由于缓存的最后合并而出现,但是这是从我们在基本0成本的离开时刻开始的。我们只是在
IO调度器合并函数被利用的时候,禁用rebtree前部门查找。
Nov 11 2002, Jens Axboe <jens.axboe@oracle.com>