Deadline IO scheduler tunables
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.
この小さなファイルでは、deadline io schedulerがどのように動作するのかを文章化しようとしています。特に、パワーユーザーが関心を抱くであろう、公開されたチューニングできる調整に関して明らかにしていきます。
Selecting IO schedulers
Refer to Documentation/block/switching-sched.rst for information on selecting an io scheduler on a per-device basis.
デバイス毎にio schedulerを選択する情報に関しては、Documentation/block/switching-sched.rstを参照してください
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.
deadline io scheduler の目的は、要求に対してstart service timeを保障しようとするものである。read latencyに注目し、それを調整することができます。io schedulerに初めてread requestが到達した場合、current_ time + read_expireのdeadlineが割り当てられます。これらの単位はmillisecondsです。
write_expire (in ms)
Similar to read_expire mentioned above, but for writes.
read_expireを同じようなものですが、これはwriteに関するものです。
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.
要求は、それぞれのデータの方向(read / write)のbatchとしてグループ化されます。これらは、セクター順序で処理されます。余計なseekを限定するために、期限が切れたexpireはbatch館でのみチェックされます。fifo_batchは、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.
このパラメータは、リクエスト毎のlatencyと、スループット保障の間でのバランスを調整するものです。low lantencyが重要だと考えれば、小さい値が有益です（1を指定すると、最初に来たものを最初に処理する振る舞いをします）。fifo_batchを増価させる事で、一般的にスループットが良くなりますが、latencyはばらつきます。
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 scheduker queueから、block device dispatch queueに対して要求を多く動かさねばならない場合、常に読み込みを優先させなければならないです。しかし、書き込みを無制限に枯渇させたくはないです。そこで、writes_starvedはどれだけの回数を読み込みから書き込みに優先させるかを制御します。writes_starvedの回数実行されると、readと同じ優先度で、writeがdispatchされます。
front_merges (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.
既にqueueにある要求に隣接するio schedulerに要求が来る場合があります。この場合、その要求の後ろに収まる、あるいは、前に収まります。これは、back merge candidateあるいはfront merge candidateと呼ばれます。ファイルの通常のレイアウト方法では、バックマージはフロントマージよりもはるかに一般的です。一般の作業負荷では、マージ要求に対するフロントへの処理を試みるために時間を費やすことは時間の無駄であると認識できるかもしれません。
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.
front_mergesを0にセットする事で、この機能を無効化できます。キャッシュされたlast_merge hintに基づいて再びFront mergeされる可能性はありますが、基本的には0 costであるため、何もしません。io schedulerのmerge functionが呼びされたときの、rbtree front sector lookupを単純に無効化するだけです。
Nov 11 2002, Jens Axboe ＜jens.axboe＠oracle.com＞
もともと、Linux Kernelのソースコードの一部なので、GPLv2扱いになる（はずの認識）。
https://www.kernel.org/doc/html/latest/index.html
Licensing documentation
The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing