정확한 블록 장치 유형에 따라 달라지는 경우 각 장치 유형에 대한 기본 I/O 스케줄러는 무엇입니까?
배경 정보
Fedora 29에는 4.19 시리즈의 Linux 커널이 포함되어 있습니다. (기술적으로 초기 버전은 4.18 시리즈 커널을 사용했지만, 4.19 커널은 일반적인 소프트웨어 업데이트를 통해 설치되었습니다.)
버전 4.19부터 메인라인 커널은 CONFIG_SCSI_MQ_DEFAULT. default y즉, Fedora 관련 패치를 적용하지 않고 Linus에서 릴리스한 트리를 사용하면 얻을 수 있는 것입니다. SCSI 및 SATA 장치는 기본적으로 새로운 다중 대기열 블록 계층을 사용합니다. (리눅스는 SATA 장치를 SCSI로 취급하고SAT 표준).
이는 이전 코드를 제거하기 위한 임시 단계입니다. 이제 모든 이전 코드가 제거됩니다.버전에서4.215.0, 4.20 이후의 다음 커널 버전입니다.
새로운 MQ 시스템에서 블록 장치는 새로운 I/O 스케줄러 세트를 사용합니다. 여기에는 none, mq-deadline, 및 가 포함됩니다 bfq. 메인라인 4.19 커널에서 기본 스케줄러 설정은 다음과 같습니다:
대신 BFQ를 기본값으로 사용하는 것이 제안되었습니다 mq-deadline. 이 제안은 버전 4.19에서는 허용되지 않았습니다.
기존 SQ 블록 계층의 경우 기본 스케줄러는 BFQ와 가장 유사한 CFQ입니다.
=> 커널의 기본 I/O 스케줄러는 SCSI/SATA, MMC/eMMC 등 장치 유형에 따라 다를 수 있습니다.
CFQ는 어느 정도의 "공정성" 및 I/O 우선순위 지정을 지원하려고 시도합니다( ionice). 그것은 다양한 복잡성으로 나타납니다. BFQ는 더 복잡합니다. ionice특정 I/O를 자동으로 분류하고 우선순위를 지정하는 휴리스틱도 지원합니다. deadline스타일 디스패치가 더 간단합니다. ionice전혀 지원되지 않습니다.
=> Linux 기본 커널 구성, SATA 장치 및 기타 사용자 공간 정책(예: 규칙 없음 udev)을 사용하는 사용자는 4.19에서 동작 변경 사항을 볼 수 있습니다. 한 번 효과가 있었던 것은 ionice더 이상 작동하지 않습니다.
그러나 Fedora에는 특정 커널 패치/구성이 포함되어 있습니다. Fedora에는 기본 규칙과 같은 사용자 공간 정책도 포함되어 있습니다 udev.
Fedora Workstation 29는 기본 I/O 스케줄러로 무엇을 사용합니까? 정확한 블록 장치 유형에 따라 달라지는 경우 각 장치 유형에 대한 기본 I/O 스케줄러는 무엇입니까?
답변1
페도라 29가 함께 제공됩니다2016년 4월 18일핵심. CFQ가 기본값인 것 같습니다.
$ grep CONFIG_DEFAULT_IOSCHED= /boot/config-4.18.16-300.fc29.x86_64
CONFIG_DEFAULT_IOSCHED="cfq"
$ grep CONFIG_SCSI_MQ_DEFAULT /boot/config-4.18.16-300.fc29.x86_64
# CONFIG_SCSI_MQ_DEFAULT is not set
$ cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
이 글을 쓰는 시점(2018년 11월 24일) 기준으로,4.19.3F29에 대한 업데이트로 사용 가능합니다. 그러나 구성 옵션은 변경되지 않은 것 같습니다.
4.20.0(RC1)은 "Rawide" 개발 트리에 있습니다. 해당 개발 트리 커널에서 CFQ는아직기본값이며 CONFIG_SCSI_MQ_DEFAULT아직 설정되지 않았습니다. Fedora 커널 목록은 다음 위치에 있습니다.https://lists.fedoraproject.org/archives/list/[이메일 보호됨]/이것이 바뀌어야 하는지 논의하기에 가장 좋은 곳입니다.
답변2
귀하의 선택에 도움이 될 수 있는 일부 정보
저는 BFQ의 저자 중 한 명이므로 거의 무관심합니다. :) 그러나 반복 가능한 테스트를 통해 얻은 수치만 보고하겠습니다.
우리는 SD 카드, eMMC, HDD, SATA SSD 및 NVMe SSD에서 BFQ를 테스트해 왔습니다. HDD 및 SSD의 경우 단일 디스크 및 RAID 구성을 사용하여 테스트했습니다.
처리량 측면에서 결과는 다음과 같이 요약될 수 있습니다. SD 카드, eMMC, HDD(단일 및 RAID)의 처리량은 감소하지 않습니다. 이에 비해 HDD를 사용할 경우 특정 작업 부하에서 약 20~30%의 이득을 얻을 수 있습니다.
SSD에서는 처리량 손실만 발생
- 무작위 동기식 I/O 사용: 평균 SSD의 경우 약 2-3%, 매우 빠른 NVMe SSD의 경우 최대 10-15%. 워크로드는 BFQ를 가장 어려운 조건에 놓도록 설계되었기 때문에 18%의 손실을 달성했지만[1] 다른 타사 테스트에서는 최악의 손실이 약 10%였습니다. 이 페널티는 주로 BFQ가 최소 I/O 스케줄러가 아니라는 사실에 기인합니다. 우리는 이 문제를 해결하기 위해 열심히 노력하고 있습니다. 이는 간단하지 않습니다. 이 격차를 메우려면 시간이 필요합니다.
- 매우 빠른 SSD에서만 I/O 쓰기: 약 5-10%. 이는 I/O 요청 태그 문제 때문입니다. 우리는 해결책을 찾았습니다. 우리는 이 문제가 중요하지 않다고 생각하기 때문에 To Do List의 다른 항목에 더 우선순위를 둡니다. 그렇게 생각하지 않는다면 우리는 우선순위를 바꿀 용의가 있습니다.
위의 오버헤드로 인해 BFQ는 상용 CPU에서 400-500 KIOPS 이상을 처리할 수 없습니다.
오디오/비디오 플레이어와 같이 시간에 민감한 애플리케이션의 응답성과 대기 시간 측면에서 결과는 타의 추종을 불허합니다. 예를 들어, BFQ 애플리케이션은 백그라운드 I/O 워크로드에 관계없이 드라이브가 유휴 상태인 것처럼 빠르게 시작됩니다. 다른 스케줄러를 사용하면 애플리케이션이 10배 더 오래 걸리거나 심지어 전혀 시작하지 못할 수도 있습니다(백그라운드 워크로드가 종료될 때까지)[1].
또한 서버와 같은 워크로드의 경우 BFQ는 총 대역폭에 도달하면서 각 클라이언트(또는 컨테이너, VM 또는 스토리지를 공유하는 다른 유형의 엔터티)에 필요한 I/O 대역폭 비율을 보장할 수 있습니다. 처리량은 I/O 제어를 위한 다른 솔루션에서 달성한 처리량과 비교할 수 없습니다[2].
마지막으로, 일부 특정 워크로드에 대해 질문이 있는 경우 기꺼이 테스트해 드리겠습니다.
[1]http://algo.ing.unimo.it/people/paolo/disk_sched/results.php