예산을 계산하는 공식은 단순해요. 최대 예산 Bmax는 추정된 디스크 피크 처리율(Rest)에 최대 시간 슬라이스 Tmax를 곱한 값이거든요. 문제는 이 Rest라는 값 하나가 틀어지면 BFQ의 전체 예산 계산이 도미노처럼 흔들린다는 점이에요. 논문은 실제로 이 추정기가 이질적인 디스크 환경에서 얼마나 쉽게 망가지는지를 실험으로 확인했는데, 정확히 뭐가 문제였을까요?
피크 레이트 추정기란 무엇이고 왜 필요한가
BFQ와 BFQ+가 어떤 애플리케이션에든 배정할 수 있는 최대 예산 Bmax는 추정 피크 처리율 Rest에 Tmax를 곱한 값으로 계산돼요. 그래서 Rest가 실제 디스크 피크 속도보다 지나치게 높으면 애플리케이션들이 부당하게 예산 타임아웃에 걸릴 확률이 올라가고, 반대로 Bmax가 필요 이상으로 커지면 서비스 보장 자체가 불필요하게 나빠져요. 결국 Rest를 얼마나 정확하게 추정하느냐가 BFQ 전체 성능의 상한선을 결정하는 셈이에요.
이 추정기는 서비스 대상이던 애플리케이션이 비활성화될 때마다 실행되는데, 논문은 최소 20ms 이상 서비스를 받은 경우에만 추정을 수행하도록 정했어요. 더 짧은 구간에서 측정한 값은 순간적인 스파이크에 휘둘리기 쉬워서 걸러낸다는 이유예요.
원래 추정기가 최댓값만 기억했던 방식
BFQ의 원래 추정기가 하는 일은 단순했어요. 방금 비활성화된 애플리케이션이 서비스받는 동안 전송한 섹터 수를 활성 시간으로 나눠 측정 처리율 Rmeas를 구하고, 이 값이 기존 추정치 Rest보다 크면 그냥 Rest를 Rmeas로 덮어썼어요. 얼핏 합리적으로 보이지만, 이 단순한 최댓값 갱신 방식이 실제로는 두 가지 함정에 취약했다고 논문은 밝혀요.
최댓값 방식이 무너진 두 가지 이유
첫 번째 함정은 Zone Bit Recording(ZBR)이에요. 회전형 디스크는 바깥쪽 구역일수록 더 많은 섹터가 같은 회전 속도로 지나가기 때문에 안쪽보다 빠르게 읽혀요. 논문이 실측한 MAXTOR STM332061 디스크는 구역에 따라 피크 속도가 55MB/s에서 약 90MB/s까지 벌어졌는데, 최댓값만 저장하는 추정기는 이 국소적으로 가장 빠른 구역의 속도에 수렴해버려서 디스크 전체를 대표하지 못하는, 지나치게 낙관적인 값으로 고정돼버려요.
두 번째 함정은 디스크 드라이브 내부 캐시예요. 요청이 이 캐시에 적중하면 실제 매체 전송 속도가 아니라 훨씬 빠른 버스 속도로 전송된 것처럼 측정될 수 있는데, 이런 예측하기 어려운 스파이크가 발생하면 Rest가 실제 디스크 피크 속도보다 훨씬 높은 값으로 튀어 오른 채 그대로 굳어버려요. 두 문제 모두 “한 번 튄 값을 영구히 최댓값으로 고정한다”는 원래 방식의 구조적 약점에서 비롯돼요.
저역통과 필터로 바꾼 새 추정기
논문이 내놓은 해법은 최댓값을 무조건 저장하는 대신, 새 측정치를 완만하게 반영하는 이산 저역통과 필터예요. 디스크의 평균 피크 처리율은 비교적 안정적인 값이라는 전제 아래, Rest가 이미 Rmeas보다 낮거나(즉 갱신이 필요하거나), 애플리케이션이 랜덤으로 판정되지 않았는데도 최대 시간 슬라이스 Tmax 안에 예산을 다 못 쓴 경우(Bmax가 너무 크다는 신호)에 한해 Rest를 다음 식으로 갱신해요.
Rest = (7/8) × Rest + (1/8) × Rmeas
이 7/8이라는 계수(α)는 논문이 여러 차례 튜닝한 끝에 확정한 값이에요. 논문은 이 필터가 실험에 사용한 모든 디스크에서 진동을 효과적으로 완화하고 실제 피크 처리율로 수렴하는 데 성공했다고 밝혀요. 애플리케이션이 예산을 시간 안에 다 못 쓰는 상황을 갱신 조건에 새로 추가한 것도 주목할 만해요. Bmax가 Tmax와 Rest의 곱인 만큼, 예산을 다 못 쓴다는 건 Rest가 과대평가됐다는 간접 증거로 볼 수 있기 때문이에요.
정확한 추정치가 나머지 휴리스틱의 토대가 된다
피크 레이트 추정이 정확해지면 Bmax도 함께 정확해지고, 그 위에 쌓이는 예산 피드백-루프와 low-latency 휴리스틱이 계산하는 모든 값의 기준점이 안정돼요. 논문이 konsole 기동 시간을 20초대에서 3초대로 낮춘 결과를 두고 “이 논문에서 설명한 휴리스틱들의 조합” 덕분이라고 표현한 것도 이런 이유예요. 다만 처리량과 지연 시간을 아무리 잘 맞춰도 남는 문제가 하나 있는데, 바로 쓰기(write) 요청이 읽기(read) 요청을 굶기는 현상이에요.
자주 묻는 질문
Q1. 디스크 피크 레이트 추정이 왜 중요한가요?
BFQ가 계산하는 최대 예산 Bmax는 추정된 피크 처리율(Rest)에 최대 시간 슬라이스 Tmax를 곱한 값이기 때문에, Rest를 잘못 추정하면 Bmax도 함께 부정확해져 예산 타임아웃이 부당하게 발생하거나 서비스 보장이 불필요하게 나빠질 수 있어요.
Q2. 원래 추정기는 어떤 방식으로 동작했나요?
애플리케이션이 서비스를 마칠 때마다 실제 측정된 처리율(Rmeas)을 계산해서, 기존 추정치(Rest)보다 크면 그 값으로 그냥 덮어쓰는 단순한 최댓값 갱신 방식이었어요.
Q3. 원래 추정기가 부정확했던 이유는 무엇인가요?
Zone Bit Recording 때문에 디스크 바깥쪽 구역은 안쪽보다 훨씬 빠른 속도로 읽히는데, 최댓값만 저장하는 추정기는 이 국소적으로 빠른 값에 수렴해버려 디스크 전체를 대표하지 못하는 값이 됐어요.
Q4. 캐시 히트는 추정에 어떤 문제를 일으켰나요?
디스크 드라이브 내부 캐시에 요청이 적중하면 실제 매체 속도보다 훨씬 빠른 버스 속도로 전송된 것처럼 측정될 수 있는데, 원래 추정기는 이런 순간적인 스파이크값까지 그대로 최댓값으로 저장해버렸어요.
Q5. 새 추정기는 이 문제를 어떻게 해결했나요?
논문은 최댓값을 그대로 저장하는 대신 이산 저역통과 필터를 도입해서, Rest를 (7/8)*Rest + (1/8)*Rmeas 식으로 완만하게 갱신하도록 바꿔 스파이크의 영향을 줄이고 실제 평균 피크 속도로 수렴하게 만들었어요.
Q6. 20ms보다 짧은 서비스 시간은 왜 추정에 반영하지 않나요?
너무 짧은 서비스 구간에서 측정한 값은 순간적인 스파이크에 크게 좌우되기 때문에, 논문은 최소 20ms 이상 서비스받은 경우에만 추정기를 실행해 단기 잡음을 걸러내요.
BFQ 비디오 재생 벤치마크: 반응성을 높인 대가로 프레임이 얼마나 떨어졌나
BFQ+의 low-latency 휴리스틱이 반응성을 높이는 대신 소프트 실시간 애플리케이션에 어떤 지연 시간 대가를 요구하는지 논문의 비디오 재생 벤치마크로 확인합니다.
NCQ가 켜지면 디스크 스케줄러 보장이 무너지는 이유 (BFQ 논문 실측)
Native Command Queueing이 활성화되면 BFQ, CFQ 같은 OS 스케줄러의 공정성·지연 보장이 어떻게 무력화되는지 논문의 실측 데이터로 설명합니다.
BFQ+ vs BFQ vs CFQ 실측 벤치마크: 처리량과 앱 기동 시간 비교
BFQ 논문이 세 대의 리눅스 시스템에서 실측한 집계 처리량과 bash·konsole 기동 시간 벤치마크 결과를 수치 그대로 정리합니다.