LAVD와 sched_ext: 지연 민감도와 CPU 선택

기준: sched_ext의 계약은 Linux 6.18 문서, LAVD의 설계 변화는 2025년 12월 12일 Changwoo Min의 LPC 발표를 기준으로 합니다. 현재 릴리스의 모든 구현을 분석하거나 실제 하드웨어에서 성능을 재현한 글은 아닙니다.

1. sched_ext는 정책을 넣는 경계다

sched_ext는 BPF로 스케줄링 정책을 정의하는 Linux scheduling class입니다. 정책은 struct sched_ext_ops의 콜백을 통해 연결됩니다. scx_lavd는 이 틀을 사용하는 한 구현이지, sched_ext 자체의 다른 이름이 아닙니다.

Linux 6.18에서 BPF 스케줄러를 기본 방식으로 로드하면 SCHED_NORMAL, SCHED_BATCH, SCHED_IDLE, SCHED_EXT 태스크가 대상이 됩니다. SCX_OPS_SWITCH_PARTIAL이면 그중 SCHED_EXT만 맡습니다. 모든 scheduling class가 통째로 교체된다는 뜻은 아닙니다. BPF 정책이 없을 때 SCHED_EXT 태스크는 일반 fair 정책으로 처리됩니다. [1]

그림 1. 깨어난 태스크가 실행 후보가 되는 경로

1 · CPU 선택 힌트ops.select_cpu()가 배치 후보를 고른다. 그 CPU에서 실행한다는 확정은 아니다.
2 · 큐에 배치ops.enqueue() 등에서 DSQ나 정책 내부 큐로 연결한다. local DSQ로 직접 삽입하는 경로도 있다.
3 · 실행할 작업 공급필요하면 ops.dispatch()가 작업을 공급한다. CPU는 자신의 local DSQ에서 실행할 태스크를 얻는다.

공식 문서를 바탕으로 다시 그린 개념도입니다. 이동 불가능한 태스크에서는 select_cpu가 생략될 수 있습니다. select_cpu에서 직접 local DSQ에 넣으면 enqueue도 건너뛸 수 있으므로 모든 깨움이 세 콜백을 순서대로 통과하지는 않습니다.

BPF 종료·오류나 실행 가능한 태스크의 정체 감지 시 fair 스케줄러로 복귀하는 장치도 있습니다. 그러나 복귀 기능이 특정 서비스의 지연 상한까지 보증하지는 않습니다. 커널과 scx 버전을 함께 기록해야 하며, sched_ext의 콜백·상수·kfunc ABI가 버전 사이에서 안정적이라고 가정하면 안 됩니다. [1]

2. 가상 마감시각은 현실의 완료 보장이 아니다

LAVD는 Latency-criticality Aware Virtual Deadline의 약자입니다. 태스크의 지연 민감도를 추정하고 이를 가상 마감시각이나 time slice 같은 결정에 반영합니다. BPF 부분은 스케줄링 결정을, Rust 부분은 topology 정보 제공과 BPF 로딩 등의 지원을 맡습니다. [2]

2025년 발표는 wake-up·blocking 빈도와 실행 시간을 지연 민감도의 입력으로 설명합니다. 게임처럼 여러 태스크가 깨우기와 대기를 반복하며 한 번의 사용자 응답을 완성하는 작업이 출발점입니다. 단순히 CPU를 오래 쓰는 태스크가 항상 먼저 실행되어야 한다는 규칙과 다릅니다. [3, 슬라이드 3]

구분	물어보는 질문	혼동하면 안 되는 것
지연 민감도	지금 이 태스크가 늦어지면 이어지는 응답도 늦어지는가?	단순 CPU 사용률 또는 사용자가 지정한 실시간 우선순위
연산 수요	작업을 처리하는 데 어느 정도 CPU 능력이 필요한가?	대기 시간이 길다는 사실만으로 추정한 연산량
가상 마감시각	정책 내부에서 실행 순서를 어떻게 비교할 것인가?	실제 시각의 완료 계약이나 hard real-time 보장

따라서 LAVD의 deadline을 읽을 때는 SCHED_DEADLINE 설정이나 애플리케이션의 실제 제한 시간과 동일시하지 않습니다. 알고리즘의 순서 결정 값이 작아졌다는 것과, 사용자가 누른 버튼에 대한 응답이 정해진 시간 안에 끝났다는 것은 별도의 주장입니다.

3. CPU 선택에는 에너지와 처리 능력도 들어간다

발표의 EMAS(Energy Model Aware Scheduling)는 필요한 연산 능력을 만족시키는 CPU 조합을 에너지 모델로 찾는 접근입니다. 로딩 시 EMO(Energy Model Optimizer)가 휴리스틱으로 후보를 구성하고, 태스크의 연산 수요와 performance-criticality를 CPU 종류에 맞추는 문제가 이어집니다. [3, 슬라이드 11–15]

그림 2. 실행 순서와 CPU 조합은 서로 다른 판단

관측태스크의 실행·대기 이력과 CPU의 처리 능력·에너지 특성을 구분한다.
정책 판단응답이 급한 작업의 순서와, 연산 수요를 감당할 코어 조합을 함께 고려한다.
배치 결과 확인실제 지연·처리량·전력과 이동 비용을 측정한다. 모델의 예측만으로 효과를 확정하지 않는다.

발표를 해석한 설명용 도식입니다. 실제 함수 호출 순서나 계측 결과를 표시한 것은 아닙니다.

서로 다른 코어를 가진 CPU에서 “가장 빠른 코어 하나”와 “여러 중간 코어” 중 어느 쪽이 유리한지는 작업의 병렬성과 장비의 특성에 달려 있습니다. 슬라이드 14의 CPU 번호·용량 범위는 그 예제의 값입니다. 자신의 장비에 같은 번호나 임계값을 복사할 근거가 아닙니다.

또한 태스크 하나를 아무 코어로나 나눠 실행할 수는 없습니다. 직렬로 이어지는 의존 관계, CPU affinity, 캐시 이동 비용을 따로 살펴야 합니다. 지연을 줄이려고 이동을 늘린 결과가 오히려 캐시 효율을 떨어뜨리는지 확인하는 것은 평가자의 몫입니다.

4. 입력 처리와 백그라운드 작업을 나란히 놓기

다음은 개념을 이해하기 위한 가상 상황이며 LAVD의 계산식을 재현한 시뮬레이션이 아닙니다. A는 입력을 받아 짧게 처리한 뒤 B를 깨우고, B는 화면에 보일 결과를 계산합니다. C는 독립적인 백그라운드 압축 작업입니다.

관측 장면	해석	확인할 증거
A가 짧게 실행하고 대기	사용률은 낮아도 응답 경로의 앞부분일 수 있다.	A가 깨어난 시각과 실제 실행 시작 시각
A가 B를 깨움	A만 빨리 실행하고 B가 오래 기다리면 전체 응답은 늦다.	B의 runnable 대기와 실행 시간
C가 CPU를 계속 사용	계속 실행 가능하다는 사실과 대화형 응답의 중요도는 다르다.	C의 처리량이 지나치게 희생되는지 여부

이 예에서 CPU 전체 평균 사용률만 보면 A가 왜 중요한지 놓치기 쉽습니다. 반대로 A를 빨리 실행한 사실만 보고 성공을 선언하면 B 이후의 지연이나 C의 처리량 손실을 놓칩니다. 하나의 수치 대신 작업의 연결 관계와 완료 시점을 함께 관측해야 합니다.

lock을 쥔 태스크가 실행하지 못해 다른 태스크가 기다리는 경우도 별도 문제입니다. 2025년 발표의 lock-holder preemption, NTsync, 큰 서버와 자원 격리 논의는 당시의 개선·향후 방향으로 읽습니다. 그 목록만으로 현재 구현의 지원 여부를 판정하지 않습니다. [3, 슬라이드 18–20]

5. 효과를 확인하려면 무엇을 고정해야 하나

공식 발표의 Snapdragon 개발 보드 실험은 특정 조건의 예시입니다. 이 글에서는 FPS 수치를 제품 전반의 성능 향상률로 환산하지 않습니다. 영상 음성·Q&A를 검토하거나 벤치마크를 직접 재현하지도 않았습니다. [3, 슬라이드 16–17]

실험을 설계한다면 다음 항목을 먼저 고정합니다. 아래 목록은 이 글의 평가 제안이며, 이미 얻은 측정 결과가 아닙니다.

소프트웨어: 정확한 커널·scx commit, 설정, 게임이나 애플리케이션 버전, LAVD 옵션.
하드웨어: CPU topology, affinity, 전력 제한, 온도 조건, GPU와 메모리 구성.
작업 조건: 같은 입력·구간·백그라운드 부하. 워밍업과 반복 순서를 기록해 열 상태 차이를 줄입니다.
응답: 평균 FPS뿐 아니라 frame time 분포와 긴 지연 구간, 가능하면 입력부터 완료까지의 시각.
비용: 백그라운드 처리량, CPU 이동, 동일 구간의 에너지. CPU 사용률을 전력계의 대체값으로 쓰지 않습니다.
복귀: 정책 종료·오류 시 실제 서비스가 어떻게 회복되는지 통제된 시험 환경에서 따로 확인합니다.

꼬리 지연을 비교할 때는 백분위수 하나만 적지 말고 표본 수와 실행 시간을 함께 남깁니다. 측정 도구 자체가 부하를 만들 수 있고, CPU 스케줄러 변경만으로 GPU 대기나 저장장치 병목이 해결된다고 가정할 수도 없습니다.

6. 출처와 읽은 범위

Linux 6.18: Extensible Scheduler Class. 정책 적용 범위, DSQ, 콜백과 복귀 조건을 확인했습니다. 기존 사이트의 v6.18.37 sched_ext 문서 해설과 함께 읽을 수 있습니다.
scx_lavd README, commit 237b4db3. LAVD의 기본 목표와 BPF·Rust 역할을 확인한 고정 문서입니다. 현재 실행 바이너리의 버전이나 전체 소스 검증을 뜻하지 않습니다.
Changwoo Min, The Current Status and Future Direction of the LAVD Scheduler, LPC 2025. 공식 PDF 21쪽의 추출 텍스트 전체와 CPU 조합·실험 결과 화면(14, 16, 17쪽)을 확인했습니다. 슬라이드의 이미지나 제3자 게임 화면은 이 사이트에 재게시하지 않았습니다.

LinkedIn에서 Yiwei Lin이 공유한 자료를 계기로 원문을 확인했습니다. 발표자는 Changwoo Min이며, 공유자와 구분합니다. 공유 날짜·계정 전체 이력은 이 글의 근거 범위가 아닙니다. 자료 대조일은 2026년 10월 13일입니다.

관련 읽기: scheduler tick · RT scheduling class · Scheduler 목록