반응성을 높이겠다고 다른 애플리케이션의 가중치를 깎아 먹으면, 그 대가는 결국 누군가 치러야 해요. Low-latency 휴리스틱이 신생 애플리케이션의 가중치를 최대 10배까지 끌어올리는 방식으로 반응성을 얻는다면, 그 손해는 어디로 갈까요? 논문은 이 질문에 가장 정직하게 답하기 위해 비디오 재생이라는 실전 시나리오를 벤치마크로 골랐어요.
왜 하필 비디오 재생을 시험대로 삼았나
논문은 low-latency 휴리스틱의 리트머스 시험지가 “이 휴리스틱이 비인터랙티브 애플리케이션의 지연 시간을 얼마나 악화시키는가”라고 못박아요. 그리고 비디오 플레이어 같은 소프트 실시간 애플리케이션이야말로 이 보장 훼손에 가장 민감한 부류라고 짚어요. 사용자가 반응성 향상을 위해 백그라운드 다운로드 속도가 조금 느려지는 건 너그럽게 받아들일 수 있지만, 재생 중이던 영상이 눈에 띄게 끊긴다면 그건 다른 차원의 문제이기 때문이에요.
벤치마크 설계: mplayer와 bash를 동시에 돌리기
벤치마크는 30초 분량의 중간 해상도 고부하 동영상 클립을 mplayer로 재생하는 동안, 캐시를 비운 상태로 bash 명령을 3초 간격으로 반복 실행하고, 동시에 앞선 처리량 벤치마크에서 쓴 네 가지 워크로드 중 하나를 배경에서 함께 돌리는 방식으로 설계됐어요. 3초라는 간격은 이 벤치마크에서 CFQ가 겪는 bash 최악 기동 시간의 상한선에 맞춘 값이에요. bash 반복 실행은 mplayer가 시작한 지 10초가 지난 뒤부터 시작하는데, 이렇게 해야 bash가 가중치-상승 혜택을 온전히 받은 상태로 반복 실행되면서 최대한의 교란을 일으키기 때문이에요. mplayer가 weight raising의 이득을 누리지 못하게 하려는 의도이기도 해요.
측정은 재생 마지막 20초, 즉 교란이 가장 심한 구간에서 드롭된 프레임 수를 세고, 초당 27프레임 재생을 가정해 보수적인 프레임 드랍률로 환산하는 방식으로 이뤄졌어요. 논문은 가장 느린 디스크를 장착한 첫 번째 시스템에서 이 벤치마크를 진행했다고 밝히는데, 디스크가 느릴수록 BFQ+가 겪는 성능 저하를 더 뚜렷하게 드러낼 수 있기 때문이에요.
결과: CFQ 대비 최대 1.6배
측정 결과, 이 시스템에서 BFQ+가 인터랙티브 애플리케이션에 낮은 지연을 보장하는 대가로 치른 프레임 드랍률은 CFQ의 1.6배를 넘지 않았어요. 기동 시간을 최대 9배까지 줄인 반응성 개선의 대가가 프레임 드랍 1.6배 선에서 그쳤다는 건, 논문 저자들이 애초에 목표했던 균형점, 즉 “인터랙티브 애플리케이션의 반응성을 극적으로 개선하면서도 소프트 실시간 애플리케이션의 지연은 크게 늘리지 않는다”는 목표가 실제로 달성됐다는 걸 보여주는 수치예요.
원래 BFQ가 가장 나빴던 지점
흥미로운 건 세 스케줄러 중 원래 BFQ가 가장 나쁜 성능을 보인 워크로드예요. 읽기·쓰기가 섞인 워크로드(5r5w-seq, 5r5w-rand)에서 BFQ는 가장 저조한 결과를 냈는데, 이 워크로드에서 디스크 시간의 상당 부분을 쓰기 요청에 내줬기 때문이라고 논문은 설명해요. 반면 write throttling 휴리스틱을 가진 BFQ+는 같은 워크로드에서도 CFQ 대비 상대적 성능이 나빠지지 않았어요. 쓰기 요청 하나가 예산을 더 빨리 소진하게 만드는 계수 하나가, 비디오 재생이라는 완전히 다른 시나리오에서도 그대로 효과를 낸 셈이에요.
다섯 가지 휴리스틱이 함께 만든 균형
이 비디오 재생 벤치마크는 사실 이 논문 전체의 결론을 압축해서 보여주는 실험이에요. Low-latency 휴리스틱 하나만 놓고 보면 반응성을 위해 다른 애플리케이션을 희생시키는 것처럼 보이지만, 정확한 피크 레이트 추정, 곱셈 증가형 예산 계산, write throttling까지 다섯 휴리스틱이 함께 작동해야 비로소 반응성과 지연 시간 사이에서 이 정도로 좁은 트레이드오프 폭을 만들어낼 수 있어요. 논문은 결론에서 “이 다섯 휴리스틱이 하나로 합쳐졌을 때만” 이 결과가 나온다고 강조하는데, 낱개로 떼어놓고 보면 이해하기 쉬운 각각의 아이디어가 실제로는 서로를 보완하도록 정교하게 맞물려 설계됐다는 뜻이기도 해요.
자주 묻는 질문
Q1. 이 벤치마크는 왜 필요했나요?
인터랙티브 애플리케이션의 반응성을 높이려고 가중치를 일시적으로 올리는 low-latency 휴리스틱이, 비디오 재생처럼 반응성 혜택을 받지 못하는 소프트 실시간 애플리케이션에 어떤 대가를 요구하는지 확인하기 위한 벤치마크예요.
Q2. 벤치마크는 어떻게 설계됐나요?
30초 분량의 고부하 동영상을 mplayer로 재생하면서, 캐시를 비운 상태로 bash를 3초마다 반복 실행하고, 동시에 배경 워크로드 하나를 함께 돌리는 방식으로 설계됐어요.
Q3. bash를 mplayer 시작 10초 뒤부터 실행한 이유는 무엇인가요?
가중치-상승 혜택을 최대로 받은 bash가 최대한의 교란을 일으키도록 만들기 위해서예요. mplayer가 먼저 안정적으로 재생을 시작한 뒤에 bash를 반복 실행해야 가중치 상승 효과를 온전히 볼 수 있어요.
Q4. BFQ+는 CFQ 대비 프레임 드랍을 얼마나 더 발생시켰나요?
가장 느린 디스크를 쓴 시스템에서 측정한 결과, BFQ+가 인터랙티브 애플리케이션에 낮은 지연을 보장하는 대가로 치른 프레임 드랍률은 CFQ의 1.6배를 넘지 않았어요.
Q5. 원래 BFQ는 이 벤치마크에서 어떤 성능을 보였나요?
원래 BFQ는 읽기·쓰기 혼합 워크로드(5r5w-seq, 5r5w-rand)에서 가장 나쁜 성능을 보였는데, write throttling 휴리스틱이 없어서 디스크 시간의 상당 부분을 쓰기 요청에 내줬기 때문이에요.
Q6. write throttling은 비디오 재생 성능에 어떤 영향을 줬나요?
write throttling 덕분에 BFQ+는 읽기·쓰기 혼합 워크로드에서도 CFQ 대비 상대적 성능이 나빠지지 않았어요. 원래 BFQ가 겪은 프레임 드랍 증가를 이 휴리스틱이 막아준 셈이에요.
NCQ가 켜지면 디스크 스케줄러 보장이 무너지는 이유 (BFQ 논문 실측)
Native Command Queueing이 활성화되면 BFQ, CFQ 같은 OS 스케줄러의 공정성·지연 보장이 어떻게 무력화되는지 논문의 실측 데이터로 설명합니다.
BFQ+ vs BFQ vs CFQ 실측 벤치마크: 처리량과 앱 기동 시간 비교
BFQ 논문이 세 대의 리눅스 시스템에서 실측한 집계 처리량과 bash·konsole 기동 시간 벤치마크 결과를 수치 그대로 정리합니다.
BFQ Write Throttling: 쓰기 요청이 읽기를 굶기는 문제를 해결한 방법
디스크 쓰기가 읽기 요청을 지연시키는 구조적 원인과, BFQ+가 쓰기 과금 계수 하나로 이 문제를 완화한 write throttling 휴리스틱을 논문 기준으로 정리합니다.