CFQ에서 konsole 터미널을 띄우는 데 최악의 경우 49분이 걸렸다는 논문의 실측치는, 스케줄러 알고리즘이 잘못 설계돼서 나온 결과가 아니에요. 문제는 스케줄러 바깥, 디스크 드라이브 하드웨어 안에 있었어요. BFQ+든 CFQ든 소프트웨어 스케줄러가 아무리 정교해도 이 문제 앞에서는 무력해지는 이유가 뭘까요?
NCQ란 무엇인가
NCQ(Native Command Queueing)는 디스크 드라이브 자체가 여러 요청을 내부 큐에 받아 쌓아두고, 처리량을 높이는 방향으로 자체 판단해 순서를 재배열하는 하드웨어 기능이에요. 운영체제의 디스크 스케줄러가 순서를 정해 요청을 내려보내도, 드라이브 내부에 별도의 스케줄러가 하나 더 있는 셈이라고 볼 수 있어요. 논문은 이전 이론 연구(Checconi & Valente, 2010)에서 이미 예견됐던 문제, 즉 대부분의 주류 애플리케이션에서 NCQ 같은 디스크 내부 큐잉이 공정성과 지연 보장을 모두 위반하게 만든다는 가설을 이 논문에서 실측으로 검증했어요.
왜 내부 큐잉이 OS 스케줄러의 보장을 무력화하는가
논문은 이 문제의 원인을 두 가지로 나눠 설명해요. 첫째는 단순한 구조적 사실이에요. 일단 요청이 드라이브에 prefetch되면, 드라이브 내부 스케줄러는 처리량을 높이는 게 더 낫다고 판단하는 한 그 요청의 서비스를 얼마든지 미룰 수 있어요. OS 스케줄러가 “이 요청을 먼저 처리해야 한다”고 정해도, 드라이브가 그 순서를 다시 뒤집어버릴 수 있는 거예요.
둘째는 더 미묘한 원인인데, B-WF2Q+가 가중치 비율대로 처리량을 나누는 방식과 정면으로 충돌해요. 동기 요청만 보내는 고가중치 애플리케이션 A를 생각해보면, 이 애플리케이션은 한 번에 요청을 하나만 낼 수 있어요. 이전 요청이 완료돼야만 다음 요청을 보낼 수 있기 때문이에요(리드어헤드는 이 논의에서 제외). 그래서 이 요청이 디스크로 전달되는 순간 A의 백로그는 곧바로 비어버려요. 디스크가 유휴 대기를 하지 않고 다른 애플리케이션이 백로그를 갖고 있다면, 스케줄러는 당연히 다른 애플리케이션을 서비스하게 되는데, 이러면 A는 원래 받아야 할 높은 처리량 비율을 결국 얻지 못하게 돼요.
OS 스케줄러의 대응: 유휴 대기를 아예 꺼버리기
CFQ와 BFQ+ 모두 이 문제에 같은 방식으로 대응해요. 내부 큐잉이 활성화된 걸 감지하면 디스크 유휴 대기 자체를 꺼버리는 거예요. BFQ가 원래 동기 요청 뒤에 짧게 대기하며 순차 접근을 이어가려던 전략을 포기하고, 사실상 스케줄링 결정 대부분을 드라이브 내부 스케줄러에 위임하는 셈이에요.
실측 결과: 처리량은 남는데 보장은 무너진다
논문이 실측한 결과는 이 절충이 얼마나 위험한지를 그대로 보여줘요. 순차 워크로드에서는 BFQ+, BFQ, CFQ 세 스케줄러 모두 비슷한 성능을 냈는데, 셋 다 내부 큐잉이 있을 때 유휴 대기를 끄고 스케줄링을 사실상 드라이브에 위임하기 때문이에요. 문제는 반응성이었어요. Table 2로 정리된 실측치를 보면 CFQ의 konsole 기동 시간은 최소 14.7초에서 최대 2940초(49분)까지 벌어졌고, BFQ+는 최소 10.7초에서 최대 196초, BFQ는 최소 30.9초에서 최대 188초를 기록했어요. bash는 상대적으로 덜 극단적이었지만 BFQ+가 0.270.32초로 가장 안정적이었고, CFQ는 1.057.44초까지 벌어졌어요.
논문은 이 결과를 두고 “NCQ는 서비스 보장을 훼손하는 두 가지 문제를 비선형적으로 증폭시킨다”고 요약해요. 값의 변동 폭 자체가 워낙 커서 선형 스케일 그래프로는 제대로 표현할 수조차 없었다고 밝힐 정도예요. konsole은 사실상 쓸 수 없는 수준이 됐고, xterm도 마찬가지였어요. 이 벤치마크에서는 비디오 재생 자체가 아예 불가능해서, 논문은 NCQ 조건에서는 비디오 재생 벤치마크 결과를 따로 보고하지 않았다고 밝혀요.
그렇다고 NCQ가 항상 나쁜 건 아니다
다만 논문은 NCQ를 무조건 배척하지는 않아요. 순수 랜덤 워크로드에서는 NCQ가 확실한 처리량 향상을 가져다준다는 점도 함께 인정해요. 문제는 그 처리량 이득이 서비스 보장과 지연 시간이라는 대가를 치르고 얻어진다는 데 있어요. 이 트레이드오프를 어느 선에서 받아들일지는 워크로드 성격에 달려있는데, 반응성이 최우선인 데스크톱이라면 이 실측 결과가 시사하는 바가 명확해요. 이 반응성이 실제로 인터랙티브하지 않은 애플리케이션, 특히 비디오 재생 같은 소프트 실시간 작업에 어떤 대가를 요구하는지는 별도의 비디오 재생 벤치마크에서 더 자세히 드러나요.
자주 묻는 질문
Q1. NCQ는 무엇의 약자인가요?
Native Command Queueing의 약자로, 디스크 드라이브 자체가 여러 요청을 내부 큐에 쌓아두고 자체 판단으로 순서를 재배열해 처리하는 하드웨어 기능이에요.
Q2. NCQ가 켜지면 왜 OS 스케줄러의 서비스 보장이 무너지나요?
운영체제 스케줄러가 아무리 정교하게 순서를 정해도, 디스크 드라이브 내부의 자체 스케줄러가 그 순서를 다시 재배열하거나 미룰 수 있어서 OS 단의 공정성·지연 보장이 실효를 잃어요.
Q3. OS 스케줄러들은 NCQ 문제에 어떻게 대응하나요?
CFQ와 BFQ+ 모두 내부 큐잉이 활성화되면 디스크 유휴 대기 자체를 꺼버리는 방식으로 대응해요. 하지만 이렇게 해도 근본적인 문제가 해결되지는 않아요.
Q4. 동기 요청을 보내는 고가중치 애플리케이션에는 어떤 문제가 생기나요?
이런 애플리케이션은 한 번에 요청을 하나만 보낼 수 있어서 그 요청이 디스크로 넘어가는 순간 백로그가 비게 되는데, 디스크가 유휴 대기하지 않으면 스케줄러는 곧바로 다른 애플리케이션을 서비스하게 되어 이 애플리케이션이 받아야 할 높은 처리량 비율을 얻지 못해요.
Q5. NCQ는 실제로 얼마나 성능에 영향을 줬나요?
CFQ에서는 konsole 기동 시간이 최악의 경우 49분까지 늘어났고, BFQ+도 이 조건에서는 여전히 나쁜 성능을 보였을 만큼 NCQ가 서비스 보장에 미치는 영향은 논문에서 '시스템을 쓸 수 없게 만드는 수준'이라고 표현될 정도로 심각했어요.
Q6. NCQ 자체는 항상 나쁜 기능인가요?
아니요. 순수 랜덤 워크로드에서는 NCQ가 확실한 처리량 향상을 가져다준다고 논문도 인정해요. 문제는 그 이득이 서비스 보장과 지연 시간이라는 대가를 치르고 얻어진다는 점이에요.
BFQ 비디오 재생 벤치마크: 반응성을 높인 대가로 프레임이 얼마나 떨어졌나
BFQ+의 low-latency 휴리스틱이 반응성을 높이는 대신 소프트 실시간 애플리케이션에 어떤 지연 시간 대가를 요구하는지 논문의 비디오 재생 벤치마크로 확인합니다.
BFQ+ vs BFQ vs CFQ 실측 벤치마크: 처리량과 앱 기동 시간 비교
BFQ 논문이 세 대의 리눅스 시스템에서 실측한 집계 처리량과 bash·konsole 기동 시간 벤치마크 결과를 수치 그대로 정리합니다.
BFQ Write Throttling: 쓰기 요청이 읽기를 굶기는 문제를 해결한 방법
디스크 쓰기가 읽기 요청을 지연시키는 구조적 원인과, BFQ+가 쓰기 과금 계수 하나로 이 문제를 완화한 write throttling 휴리스틱을 논문 기준으로 정리합니다.