BFQ Low-latency 휴리스틱: weight raising으로 앱 실행 속도를 8배 줄인 원리

같은 디스크 부하 조건에서 konsole 터미널을 실행했을 때, CFQ에서는 최대 26.9초가 걸렸지만 BFQ+에서는 2.88초 만에 떴어요. 논문 기준으로 최대 아홉 배 차이인데, 이 차이를 만든 건 스케줄링 순서 규칙이 아니라 애플리케이션의 가중치 자체를 잠깐 부풀리는 별도의 휴리스틱이에요. 도대체 가중치를 어떻게 조작했길래 이런 차이가 났을까요?

Low-latency 휴리스틱이란

Low-latency 휴리스틱은 애플리케이션이 새로 생성됐을 때 그 가중치를 일시적으로 끌어올려 더 빨리 로딩되게 만드는 이벤트 기반 알고리즘이에요. 논문은 반응성을 “애플리케이션을 빠르게 실행시키고, 인터랙티브 애플리케이션이 요청한 작업을 빠르게 수행하는 능력”으로 정의하는데, 이 정의를 그대로 구현한 첫 단계가 바로 새 애플리케이션의 가중치를 순간적으로 높이는 거예요. 애플리케이션이 인터랙티브하다면 곧 사용자 입력을 기다리며 블록될 테고, 사용자가 다시 뭔가를 요청하면 또 멈추는 패턴이 반복되는데, 이 휴리스틱은 애플리케이션이 충분히 오래 쉬었다가 다시 요청을 보낼 때마다 가중치를 다시 끌어올려요.

Crais, Brais, Trais, Tidle: 네 개의 파라미터가 만드는 곡선

새 애플리케이션이 생성되면 원래 가중치 w에 가중치-상승 계수 Crais를 곱한 값이 즉시 적용돼요. 이때 실행 파일과 라이브러리를 읽어들이는 요청이 대부분을 차지하는 구간이라, 이 배율 덕분에 훨씬 높은 처리량 비율을 받게 돼요. 동시에 애플리케이션은 가중치-상승 예산 Brais라는 값을 초기값으로 배정받는데, 서비스를 받을 때마다 이 예산이 소비된 양만큼 줄어들고, 가중치도 정확히 이 예산이 0이 되는 시점에 원래 값으로 돌아오도록 선형으로 함께 낮아져요. 섹터 하나가 서비스될 때마다 가중치는 (Crais-1)/Brais * w만큼 줄어드는 식이에요.

애플리케이션이 가중치-상승 예산을 다 쓰고 원래 가중치로 돌아온 뒤, 최소 유휴 시간 Tidle 이상 쉬었다가 다시 백로그가 생기면 가중치는 다시 Crais배로 올라가고 새로운 가중치-상승 예산 Brais가 배정돼요. 다만 여기엔 시간 제약도 걸려있어요. 가중치가 올라간 시점부터 최대 상승 시간 Trais 안에 가중치-상승 예산을 다 쓰지 못하면, 그 시점에 예산이 강제로 0이 되고 가중치도 즉시 원래 값으로 리셋돼요. 이 시간 제약이 없으면 랜덤 패턴 애플리케이션이 높은 가중치를 계속 유지하며 다른 애플리케이션의 처리량을 잠식할 수 있기 때문이에요.

논문은 여러 차례 튜닝을 거쳐 OpenOffice 스위트처럼 큰 애플리케이션도 아주 짧은 시간 안에 뜨도록 다음 값을 확정했어요. Crais=10, Brais=24MB, Trais=6초, Tidle=2초가 그 기본값이에요.

공짜가 아니다: 비인터랙티브 애플리케이션이 치르는 대가

가중치를 부풀려서 얻는 이득은 어딘가에서 대가를 치러야 해요. 논문은 이 지점을 숨기지 않고 정면으로 다뤄요. 인터랙티브하지 않은 장기 실행 애플리케이션, 예를 들어 파일 다운로드나 공유처럼 백그라운드에서 오래 도는 작업은 가중치 상승의 혜택을 전혀 받지 못하면서, 오히려 다른 애플리케이션이 일시적으로 더 큰 처리량을 가져가는 상황을 견뎌야 해요. 데스크톱 사용자라면 이 정도 처리량 저하는 압도적인 반응성 향상과 맞바꿀 만하다고 여길 수 있지만, 문제는 오디오 플레이어 같은 소프트 실시간 애플리케이션이에요. 이런 애플리케이션이 눈에 띄게 끊긴다면 사용자 만족도에 직접 타격을 주기 때문에, 논문은 이 부분을 별도 실험으로 검증했어요.

다행히 실험 결과는 우호적이었어요. Crais와 Brais를 위 값으로 설정했을 때, 비디오 플레이어 같은 비인터랙티브 시간-민감 애플리케이션이 겪는 지연 시간은 CFQ에서 겪는 지연 시간과 비교할 만한 수준으로 유지됐다고 논문은 밝혀요. 이건 BFQ+가 애초에 가지고 있던 정교한 스케줄링 정책(BFQ와 공유하는 부분)과, 초기 예산을 줄인 효과가 함께 작용한 결과예요.

서버에는 필요 없는 스위치

이 모든 게 데스크톱이나 핸드헬드처럼 반응성이 중요한 환경을 염두에 둔 설계이기 때문에, BFQ+는 low latency라는 파라미터로 이 휴리스틱 전체를 동적으로 켜고 끌 수 있게 만들었어요. 대부분의 서버처럼 반응성보다 공정성과 예측 가능한 처리량이 더 중요한 시스템에서는 이 휴리스틱을 꺼두는 편이 낫다고 논문은 명시해요. 실제로 low latency를 꺼둔 상태에서도 bash 기동 시간은 어떤 워크로드에서든 이미 0.55초 아래로 떨어졌는데, 이건 low-latency 휴리스틱 없이도 BFQ의 다른 휴리스틱들만으로 상당한 개선이 이뤄진다는 뜻이에요. 다만 그 나머지 개선분 중 상당 부분은 디스크의 실제 피크 속도를 정확히 추정하는 또 다른 휴리스틱에서 나오는데, 이건 예산 계산의 정확도를 좌우하는 별도의 문제예요.