숫자로 보면 체감이 더 확실해져요. BFQ 논문이 세 대의 리눅스 시스템에서 열 번씩 반복 측정한 결과, konsole 터미널의 기동 시간은 CFQ에서 최대 26.9초, BFQ+에서는 최대 2.88초였어요. 그렇다면 이 격차는 처리량을 얼마나 희생한 대가였을까요, 아니면 처리량까지 함께 잡은 결과였을까요?
벤치마크는 어떻게 설계됐나
논문은 회전형 디스크 한 개를 장착한 세 대의 시스템에서 리눅스 커널 2.6.32부터 3.1까지의 범위로 벤치마크를 실행했어요. 각 시스템은 기본 서비스와 백그라운드 프로세스를 모두 켠 표준 구성, 그리고 이런 잡음을 최대한 제거한 필수 구성 두 가지로 각각 두 번씩 돌렸고, 각 벤치마크는 열 번 반복해서 평균·표준편차·95% 신뢰구간을 계산했어요. 비교 대상은 원래 BFQ, 논문이 개선한 BFQ+, 그리고 당시 리눅스 기본 스케줄러였던 CFQ 세 가지였고, NCQ가 지원되는 시스템에서는 FIFO(리눅스의 NOOP 스케줄러)도 함께 비교했어요.
집계 처리량: 순차 워크로드에서 최대 24% 차이
10개의 순차 리더로 구성된 워크로드(10r-seq)와 순차 읽기·쓰기 혼합 워크로드(5r5w-seq)에서 BFQ+와 BFQ는 CFQ보다 약 24% 높은 처리량을 기록했고, 순수 읽기 워크로드에서는 디스크 피크 속도에 근접한 수준까지 도달했어요. 논문은 트레이스를 분석해서 이 결과의 원인을 예산 계산 규칙에서 찾았는데, BFQ/BFQ+의 예산이 최대치까지 빠르게 커지는 덕분에 각 리더의 순차 접근 패턴을 오래 활용할 수 있었던 반면, CFQ는 시간 슬라이스가 조금 더 짧아서(100ms 대 125ms) 프로세스 전환이 잦았다는 거예요.
반면 랜덤 워크로드에서는 모든 스케줄러가 피크 속도의 일부로 처리량이 떨어졌어요. 10개의 랜덤 리더 워크로드(10r-rand)에서는 BFQ+가 CFQ와 비슷한 수준을 기록했는데, 예산 타임아웃이 시간 기준 방식으로 되돌아가기 때문이에요. 흥미로운 지점은 랜덤 읽기·쓰기 혼합 워크로드(5r5w-rand)예요. 여기서는 write throttling을 적용하지 않은 원래 BFQ가 오히려 가장 높은 처리량을 냈는데, 이건 쓰기를 전혀 억제하지 않은 대가로 다른 벤치마크의 반응성을 잃은 결과였어요.
짧은 15초짜리 벤치마크에서는 시작 속도 자체를 비교할 수 있었어요. 원래 BFQ는 새 애플리케이션에 곧바로 최대 예산 Bmax를 배정하기 때문에 시작부터 최대 처리량을 냈고, 초기 예산을 절반으로 낮춘 BFQ+도 1~2초 안에 같은 수준에 도달했어요. CFQ는 이보다 느려서 첫 15초 동안 평균 처리량이 59.6MB/s에 그쳤어요.
반응성: bash·konsole 기동 시간
반응성 벤치마크는 네 가지 배경 워크로드가 돌아가는 동안 bash, xterm, konsole을 캐시를 비운 채로 열 번씩 실행해서 기동 시간을 측정했어요. bash 결과에서는 BFQ+가 CFQ와 BFQ보다 최대 여덟 배 낮은 기동 시간을 기록했고, 유휴 디스크에서 실행했을 때의 시간에 근접했어요. 애플리케이션 크기가 커질수록 이 격차는 더 벌어졌는데, 세 애플리케이션 중 가장 큰 konsole에서는 BFQ+가 CFQ·BFQ보다 최대 아홉 배 낮은 기동 시간을 기록하며 역시 유휴 디스크 수준에 가까운 결과를 보였어요.
다만 이 반응성은 공짜가 아니었어요. konsole 벤치마크 중 순차 읽기 워크로드(10r-seq)에서 BFQ+의 집계 처리량은 CFQ 대비 20%, BFQ 대비 36% 낮게 나왔는데, BFQ+가 konsole을 로딩하기 위한 부분 랜덤 패턴의 요청을 CFQ·BFQ보다 더 적극적으로 우선시했기 때문이에요. 논문은 이 손실이 low-latency 휴리스틱 단독이 아니라, peak-rate·throughput·fairness·write-throttling 휴리스틱까지 전부 조합돼야 이 정도의 낮은 기동 시간이 나온다고 설명해요. 이 네 가지 휴리스틱만 넣고 low-latency를 뺐다면 konsole 기동 시간이 10r-seq와 10r-rand에서도 20초 안팎에 머물렀을 거라고 밝히고 있어요.
NCQ가 켜지면 격차가 훨씬 커진다
지금까지의 수치는 모두 NCQ(Native Command Queueing)가 꺼진 환경 기준이에요. NCQ가 켜진 시스템에서는 상황이 완전히 달라지는데, CFQ는 konsole을 띄우는 데 최악의 경우 49분이 걸렸고, BFQ+는 같은 조건에서도 최악 196초 선에서 멈췄어요. 이 극단적인 차이가 왜 생기는지, 그리고 NCQ가 왜 스케줄러의 서비스 보장 자체를 무력화하는지는 디스크 드라이브 내부 큐잉이라는 별도의 구조적 문제를 들여다봐야 이해할 수 있어요.
자주 묻는 질문
Q1. 이 벤치마크는 어떤 환경에서 진행됐나요?
회전형 디스크 한 개를 장착한 세 대의 리눅스 시스템에서, 리눅스 커널 2.6.32부터 3.1까지의 범위로 진행됐고 각 벤치마크는 열 번씩 반복 실행해 평균을 냈어요.
Q2. 순차 읽기 워크로드에서 처리량 차이는 얼마나 났나요?
10개의 순차 리더로 구성된 워크로드(10r-seq)에서 BFQ+와 BFQ 모두 CFQ보다 약 24% 높은 처리량을 기록했고, 디스크 피크 속도에 가까운 수준까지 도달했어요.
Q3. konsole 기동 시간은 얼마나 차이가 났나요?
가장 부하가 큰 워크로드 기준으로 CFQ는 최대 26.9초가 걸린 반면 BFQ+는 최대 2.88초에 그쳐, 최대 아홉 배 가까운 차이를 보였어요.
Q4. BFQ+가 처리량을 희생하면서 반응성을 얻은 건가요?
일부 워크로드에서는 그래요. konsole 벤치마크 중 순차 읽기 워크로드(10r-seq)에서 BFQ+는 CFQ 대비 20%, BFQ 대비 36% 낮은 집계 처리량을 기록했는데, 그만큼 인터랙티브 요청에 디스크 시간을 더 배분했기 때문이에요.
Q5. 짧은 벤치마크(15초)에서는 어떤 스케줄러가 가장 빨리 최대 처리량에 도달했나요?
원래 BFQ는 새 애플리케이션에 곧바로 최대 예산을 배정해 시작부터 최대 처리량을 냈고, BFQ+는 1~2초 안에 같은 수준에 도달했어요. CFQ는 첫 15초 평균 처리량이 59.6MB/s로 가장 느리게 수렴했어요.
Q6. NCQ가 없는 환경과 있는 환경 중 어느 쪽에서 차이가 더 컸나요?
NCQ가 활성화된 환경에서 차이가 훨씬 크게 벌어졌어요. CFQ는 konsole을 띄우는 데 최대 49분이 걸린 반면 BFQ+는 최악의 경우에도 196초 선에서 그쳤어요.
BFQ 비디오 재생 벤치마크: 반응성을 높인 대가로 프레임이 얼마나 떨어졌나
BFQ+의 low-latency 휴리스틱이 반응성을 높이는 대신 소프트 실시간 애플리케이션에 어떤 지연 시간 대가를 요구하는지 논문의 비디오 재생 벤치마크로 확인합니다.
NCQ가 켜지면 디스크 스케줄러 보장이 무너지는 이유 (BFQ 논문 실측)
Native Command Queueing이 활성화되면 BFQ, CFQ 같은 OS 스케줄러의 공정성·지연 보장이 어떻게 무력화되는지 논문의 실측 데이터로 설명합니다.
BFQ Write Throttling: 쓰기 요청이 읽기를 굶기는 문제를 해결한 방법
디스크 쓰기가 읽기 요청을 지연시키는 구조적 원인과, BFQ+가 쓰기 과금 계수 하나로 이 문제를 완화한 write throttling 휴리스틱을 논문 기준으로 정리합니다.