요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
==============================
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.
Selecting IO schedulers
-----------------------
Refer to Documentation/block/switching-sched.rst for information on
selecting an io scheduler on a per-device basis.
------------------------------------------------------------------------------
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.
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.
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.
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.
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. 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.
Nov 11 2002, Jens Axboe <[email protected]>
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
deadline scheduler와 선택 방법
1-14`Deadline IO scheduler tunables` 문서는 deadline IO scheduler의 동작과 power user가 관심을 가질 수 있는 공개 tunable의 의미를 설명합니다.
device별 IO scheduler 선택 방법은 `Documentation/block/switching-sched.rst`를 참조하십시오.
read_expire
15-25`read_expire`의 단위는 ms입니다. deadline IO scheduler의 목표는 request가 service를 시작하는 시간을 보장하려는 것입니다. 주로 read latency에 초점을 맞추므로 이 값을 조정할 수 있습니다.
read request가 IO scheduler에 처음 들어오면 millisecond 단위로 `current time + read_expire`인 deadline을 할당받습니다.
write_expire
26-31`write_expire`의 단위는 ms이며 앞에서 설명한 `read_expire`와 같지만 write request에 적용됩니다.
fifo_batch
32-45`fifo_batch`의 단위는 request 수입니다. request를 read 또는 write 같은 특정 data direction의 `batch`로 묶고 sector가 증가하는 순서로 service합니다. 추가 seek를 제한하기 위해 deadline expiration은 batch 사이에서만 확인합니다. `fifo_batch`는 batch 하나에 들어갈 수 있는 최대 request 수를 제어합니다.
이 parameter는 request별 latency와 전체 throughput 사이의 균형을 조정합니다. low latency가 가장 중요하면 작은 값이 좋고, 값 `1`은 first-come first-served 동작을 만듭니다. `fifo_batch`를 늘리면 일반적으로 throughput이 좋아지는 대신 latency variation이 커집니다.
writes_starved
46-56`writes_starved`의 단위는 dispatch 수입니다. IO scheduler queue에서 block device dispatch queue로 request를 옮길 때 read를 항상 우선하지만 write가 무기한 starvation을 겪게 해서는 안 됩니다.
`writes_starved`는 write보다 read를 우선하는 횟수를 제어합니다. 이 횟수만큼 read를 우선한 뒤에는 read와 같은 기준으로 일부 write를 dispatch합니다.
front_merges
57-72`front_merges`는 bool 값입니다. 새 request가 queue에 이미 있는 request와 연속된 경우 기존 request 뒤에 맞으면 `back merge candidate`, 앞에 맞으면 `front merge candidate`라고 합니다.
일반적인 file layout에서는 front merge보다 back merge가 훨씬 흔합니다. 일부 workload에서는 front merge를 시도하는 시간 자체가 낭비일 수 있으며, `front_merges`를 `0`으로 설정하면 이 기능을 끕니다.
cached `last_merge` hint 때문에 front merge가 계속 발생할 수 있지만 비용이 사실상 `0`이므로 이 경로는 유지합니다. IO scheduler merge function이 호출될 때 rbtree의 front sector lookup만 비활성화합니다.
원문 기록: `Nov 11 2002, Jens Axboe <[email protected]>`.
요약과 해설
deadline-iosched.rst:1-72deadline scheduler는 read·write request에 deadline을 부여하고 batch 단위로 sector 순서에 따라 처리해 latency 상한과 throughput 사이를 조정합니다.
`fifo_batch`가 작을수록 request별 latency가 안정되고 클수록 throughput이 좋아집니다. `writes_starved`는 read 우선 정책 아래 write starvation을 막고, `front_merges=0`은 비용이 큰 front-sector 검색을 끕니다.