CONFIG_WBT 및 BFQ에 대해 읽었습니다. 내 하드 드라이브에서 WBT와 CFQ를 비교해 보았습니다. CFQ가 Linux의 대규모 비동기 쓰기 저장을 제어하려고 시도하지만 하드 디스크의 쓰기 저장 캐시로 인해 성공률이 제한된다는 것을 알고 있습니다. 내 드라이브에서 하드웨어 쓰기 캐싱을 비활성화하면(NCQ는 활성화된 상태로 유지) 제어 기능이 크게 향상되었습니다. [1]
[1]쓰기 저장 제한(CONFIG_WBT)의 구체적인 이점 확인
이제 CFQ/BFQ에서 WBT가 비활성화된 것으로 알고 있습니다. 또한 업스트림 Linux v4.19에서는 blk-mq를 scsi의 기본값으로 지정하므로 Fedora와 같은 배포판은 평가할 때 기본적으로 CFQ에서 BFQ로 전환하거나 "이전" 블록 계층으로 다시 전환해야 합니다. 그래서 BFQ에 대해 알고 싶습니다.
BFQ에는 두 가지 하드웨어 측면 휴리스틱이 있다는 것을 읽었습니다. 장치 쓰기 캐시의 영향을 완화하기 위해 쓰기를 10배로 "과충전"합니다. 또한 NCQ의 영향을 완화하기 위해 유휴 상태를 사용하려고 시도합니다. 현재 가장 혼란스러운 것은 덮어쓰기입니다.
제공되는 읽기 요청 수에 대한 쓰기 요청 수의 비율을 낮게 유지하려면 쓰기(초과) 요금 요소를 추가하기만 하면 됩니다. 작성된 각 섹터에 대해 활성 애플리케이션의 예산은 1 대신 감소됩니다. 실험 결과에서 알 수 있듯이 계수가 10이면 높은 처리량과 낮은 대기 시간을 보장하는 데 효과적인 것으로 나타났습니다.
http://algo.ing.unimo.it/people/paolo/disk_sched/bf1-v1-suite-results.pdf
/*
* Async to sync throughput distribution is controlled as follows:
* when an async request is served, the entity is charged the number
* of sectors of the request, multiplied by the factor below
*/
static const int bfq_async_charge_factor = 10;
https://elixir.bootlin.com/linux/v4.18/source/block/bfq-iosched.c#L190
(쓰기 저장 캐싱이 비활성화되었을 때 이 요소를 비활성화하는 코드가 BFQ에 없습니다. WBT에는 매우 비슷한 이유로 쓰기 저장 캐싱이 활성화되었는지 추적하는 일부 코드가 포함되어 있습니다. 원칙적으로 BFQ가 동일한 작업을 수행할 수 있다고 생각합니다. 하지만 이제 BFQ는 그럴 것 같습니다.언제나덮어쓰기(BFQ는 쓰기 저장 캐시가 있는 장치에만 필요하다고 주장하지만).
이는 비동기 쓰기가 장치 처리량에서 훨씬 낮은 비율을 차지한다는 것을 의미합니다. 이 "불공정한" 공유를 관찰할 수 있는 간단한 테스트 사례가 있습니까? 아니면 제가 잘못 이해하고 있는 걸까요?
위의 링크에는 BFQ에 대한 빠른 테스트가 포함되어 있습니다. 이는 기본 기본 설정을 사용하여 동시에 읽고 쓰는 것입니다 fio. 나는 BFQ가 독자와 작가에게 "공정한" 공유에 더 가까운 것을 제공한다고 생각합니다. (리더는 내 하드 드라이브에서 40MB/s를 기록합니다.)
답변1
v4.19에서는 과충전 계수가 10에서 3으로 감소되었습니다. 따라서 현재의 과충전 요인은 나에게 그다지 걱정되지 않습니다 :-).
cgroups I/O 제어를 연구하는 동안 bfq에서 두 가지 성가신 버그를 발견했습니다. 단일 프로세스 그룹을 통해 간단한 구성으로 대역폭 제어를 중단합니다. 이러한 버그는 이 시리즈의 처음 두 패치에서 수정되었습니다.
이러한 수정으로 인해 I/O 제어가 크게 향상되어 bfq가 쓰기로 인해 발생한 문제를 처리하는 데 사용한 덮어쓰기 요소를 줄일 수 있었습니다. 이 감소는 세 번째 패치에서 수행됩니다.
실제로 내 노트북의 하드 드라이브를 테스트하면서 v4.18 안정 커널과 v4.19 안정 커널 사이에 매우 눈에 띄는 차이를 발견했습니다. vmstat 1다음을 사용하여 동기식 읽기/쓰기 테스트를 실행하는 동안 읽기 처리량과 쓰기 처리량을 관찰했습니다 .
fio --ioengine=psync --size=2G --name=read --rw=read --name=write --rw=write
4.18 안정 커널에서는 작성기가 먼저 완료됩니다. v4.19-stable에서는 독자가 먼저 완료합니다. 그러나 역학은 더 흥미 롭습니다. v4.19에서는 vmstat 1주로 몇 가지 예외적인 예를 제외하고 리더가 쓰기 처리량 공유의 2~3배를 부여받는 것으로 나타났습니다. v4.18에서는 리더와 라이터 간의 처리량이 크게 변동됩니다.
이것은 그 자체로는 결정적이지 않습니다. 하지만 나는 명백한 가정에 대해 생각하지 않을 수 없습니다. 1) 아마도 원래의 10x 과충전에는 BFQ의 실제 오류를 보상하기 위한 상당한 "퍼지 요소"가 포함되어 있었을까요? 2) 아마도 v4.19에서는 초과 요소 3이 왜 리더가 작성자 처리량 공유의 2-3배 할당되는지 설명합니까?
나는 또한 BFQ 메일링 리스트에 이 질문을 올렸고 Paolo Valente는 나에게 답변을 주려고 노력했습니다. 그는 나에게 v4.19의 과충전 변경 사항을 지적했습니다. 그는 또한 과충전 요인이 하드웨어 쓰기 캐시에만 관련된 것이 아니라고 말했습니다.
즉, 제공된 읽기 요청에 대한 비동기 쓰기 요청의 비율을 낮게 유지함으로써,~에bfq에 따르면 순효과는 공정한 스케줄러에서 기대할 수 있는 것입니다. 즉, 수행하는 I/O 유형에 관계없이 프로세스 또는 프로세스 그룹 간에 대역폭을 공정하게 분배하는 것입니다. 이 보상 문제는 댓글로 설명해야겠죠? 그렇게 생각하신다면 그렇게 하겠습니다.
그럼에도 불구하고, bfq의 이러한 내부 "보상"의 다른 실제적인 결과는 예를 들어 여기 그림 2 및 5(그리고 다른 많은 곳)에서 보고된 비교할 수 없을 만큼 더 나은 응답 결과입니다.
http://algo.ing.unimo.it/people/paolo/disk_sched/results.php
(특히 백그라운드 쓰기의 경우를 언급하고 있습니다.) 또는 그림 1과 4의 동일한 페이지에 대한 백그라운드 쓰기의 처리량 결과입니다.
순차 I/O에 비해 무작위 I/O의 경우 상황이 더 복잡해집니다. 하지만 이야기는 다릅니다.
https://groups.google.com/forum/#!topic/bfq-iosched/yjZDn_HnLIc