BFQ 예산 타임아웃이란? 랜덤 요청이 디스크를 독점하지 못하게 막는 방법

섹터 수를 기준으로 예산을 배정하는 방식은 순차 읽기에는 잘 맞지만, 랜덤 접근만 반복하는 애플리케이션에는 이상하게 작동해요. 디스크 헤드가 계속 이리저리 튀느라 같은 양의 예산을 채우는 데 훨씬 오래 걸리기 때문이에요. 예산을 계속 다시 계산하는 피드백-루프만으로는 이 문제를 완전히 막을 수 없는데, BFQ는 이걸 어떤 별도 장치로 보완했을까요?

예산 타임아웃이란

예산 타임아웃은 BFQ가 디스크 사용에 걸어두는 시간 제약으로, 어떤 애플리케이션이 디스크 접근권을 얻은 뒤 Tmax(최대 시간 슬라이스, 기본값 125ms) 시간이 지나면 아직 백로그가 남아있어도 강제로 비활성화시키는 규칙이에요. 이 규칙이 존재하는 이유는 명확해요. 랜덤 패턴 애플리케이션이 디스크를 오래 붙잡고 있으면 처리량이 큰 폭으로 떨어지는데, 시간 기준으로 공정성을 되돌리는 이 장치가 그런 상황을 막아주는 거예요.

시간 제약만으로 부족한 이유

시간 제약을 걸어도 문제가 하나 더 남아요. 타임아웃으로 쫓겨난 애플리케이션이 다음번에도 똑같이 짧은 시간만 쓰고 금방 다시 자기 차례가 돌아온다면, 결국 디스크는 랜덤 애플리케이션들 사이를 빈번하게 오가며 탐색(seek) 오버헤드만 키우게 돼요. 그래서 BFQ는 타임아웃이 발생한 애플리케이션에 실제로 소비한 양과 무관하게 예산 전액을 과금하는 두 번째 장치를 더했어요. 이렇게 전액을 미리 차감해두면 그 애플리케이션이 다시 디스크 접근권을 얻는 빈도 자체가 줄어들어서, 랜덤 애플리케이션이 처리량을 깎아먹는 폭을 한층 더 제한할 수 있어요.

원래 규칙이 지나치게 가혹했던 세 가지 상황

논문은 실험을 거듭하며 이 원래 휴리스틱이 억울한 애플리케이션까지 처벌한다는 걸 발견했어요. 첫 번째는 순차 애플리케이션이 막 I/O를 시작한 직후예요. 디스크 헤드를 첫 섹터로 옮기는 데 든 처리량 손실이 아직 순차 접근의 이득으로 상쇄되기 전이라, 짧은 시간 동안은 랜덤 애플리케이션처럼 보일 수 있어요. 두 번째는 디스크 위주 구간을 시작하기 직전에 아주 적은 수의, 그러나 멀리 떨어진 랜덤 요청 몇 개만 보내고 곧바로 순차 I/O로 전환하는 애플리케이션이에요. 세 번째는 Zone Bit Recording 때문에 디스크의 가장 느린 구역을 읽고 있을 뿐인데 속도가 느리다는 이유만으로 “느린 애플리케이션”으로 오판되는 경우예요.

원래 BFQ는 이 세 상황 모두를 처리량에 해롭다고 간주해서, 전액 과금을 하거나 그 애플리케이션에 대해 디스크 유휴 대기 자체를 꺼버리는 방식으로 대응했어요. 하지만 논문은 이 대응이 오히려 처리량 손실과 반응성 저하를 낳는다는 걸 확인하고, 개선판인 BFQ+에서는 위 세 가지 상황 중 어디에도 이런 페널티를 적용하지 않도록 휴리스틱을 완화했어요.

CFQ의 타임 슬라이스와는 무엇이 다른가

이 시간 기반 타임아웃을 보면 CFQ의 라운드로빈 방식과 비슷해 보일 수 있어요. 하지만 결정적인 차이가 있어요. CFQ는 애플리케이션마다 항상 고정된 시간 슬라이스를 배정하는 반면, BFQ는 원칙적으로 섹터 수 기준 예산으로 순서를 정하고, 랜덤 패턴을 보일 때만 예외적으로 이 시간 기반 규칙으로 돌아가요. 논문은 이 차이 때문에 두 스케줄러가 순차 워크로드에서 처리량 격차를 보인다고 설명하는데, CFQ의 시간 슬라이스가 BFQ보다 약간 짧다 보니(100ms 대 125ms) 프로세스 전환이 좀 더 잦아지고, 그만큼 순차 접근의 이점을 덜 살리게 된다는 거예요.

공정성 장치 다음은 반응성 장치다

예산 타임아웃과 전액 과금은 어디까지나 “랜덤 애플리케이션이 처리량을 깎아먹지 못하게 막는” 방어적인 장치예요. 이것만으로는 반응성, 즉 애플리케이션을 새로 실행했을 때 얼마나 빨리 뜨는지의 문제는 풀리지 않아요. 논문이 이 반응성 문제를 풀기 위해 별도로 도입한 게 애플리케이션의 가중치를 일시적으로 끌어올리는 low-latency 휴리스틱인데, bash와 konsole의 실제 기동 시간이 최대 9배까지 차이 나는 결과가 바로 이 휴리스틱에서 나와요.