Linux CFS 스케줄러 — 왜 게임 PC와 서버 성능이 다르게 느껴지는가

## 왜 같은 코어인데 체감이 다를까

리눅스 커널을 쓰는 데스크탑 게이머와 서버 엔지니어는 같은 CFS(Completely Fair Scheduler)를 쓰면서도 전혀 다른 튜닝을 한다. 이유는 단 하나다. CFS가 공정성(fairness)을 중심으로 설계되어 있기 때문이다.

CFS는 프로세스마다 **vruntime**을 추적한다. vruntime이 가장 낮은 프로세스가 다음에 CPU를 차지한다. 빠르게 응답해야 하는 인터랙티브 프로세스는 잠깐 CPU를 쓰고 I/O 대기에 들어가기 때문에 vruntime이 낮게 유지된다. 그 결과 자연스럽게 우선권이 생긴다.

## vruntime 계산 구조

```
vruntime += delta_exec * (NICE_0_LOAD / weight)
```

nice 값이 높을수록(낮은 우선순위) weight가 작아지므로 vruntime이 빠르게 증가한다. nice 값이 낮을수록(높은 우선순위) weight가 커지므로 vruntime 증가 속도가 느리고 자주 선택된다.

```c
// kernel/sched/fair.c (단순화)
static void update_curr(struct cfs_rq *cfs_rq) {
    u64 delta_exec = now - curr->exec_start;
    curr->vruntime += calc_delta_fair(delta_exec, curr);
    update_min_vruntime(cfs_rq);
}
```

## 게임 PC의 문제: sched_latency_ns

CFS는 `sched_latency_ns`라는 시간 창 안에서 모든 runnable 프로세스가 최소 한 번 CPU를 얻도록 설계되어 있다. 기본값은 6ms~24ms (프로세스 수에 따라 동적 조정).

게임 프레임 렌더링은 16ms(60fps) 안에 끝나야 하는데, 다른 프로세스들이 이 창을 공유하면 프레임 드랍이 생긴다. 그래서 게임 머신에서는:

```bash
# /etc/sysctl.d/99-gaming.conf
kernel.sched_latency_ns = 4000000          # 4ms
kernel.sched_min_granularity_ns = 500000   # 0.5ms
kernel.sched_wakeup_granularity_ns = 250000
```

## 서버의 문제: throughput vs latency

서버(특히 배치 처리, Hadoop, 컴파일 서버)는 인터랙티브 응답이 필요 없다. 오히려 컨텍스트 스위칭을 줄이고 캐시 친화성(cache affinity)을 높이는 것이 중요하다.

```bash
# /etc/sysctl.d/99-server.conf
kernel.sched_latency_ns = 12000000        # 12ms
kernel.sched_min_granularity_ns = 1500000 # 1.5ms
kernel.sched_migration_cost_ns = 5000000  # 코어 이동 비용 높게
```

`sched_migration_cost_ns`를 높이면 프로세스가 한 코어에 더 오래 머무른다. L1/L2 캐시 히트율이 높아지고 실질 처리량이 개선된다.

## SCHED_DEADLINE과 실시간 작업

음악 제작, 실시간 오디오 처리처럼 엄격한 데드라인이 필요하다면 SCHED_DEADLINE을 쓴다.

```c
struct sched_attr attr = {
    .size        = sizeof(attr),
    .sched_policy = SCHED_DEADLINE,
    .sched_runtime  = 2 * 1000 * 1000,  // 2ms runtime
    .sched_deadline = 5 * 1000 * 1000,  // 5ms deadline
    .sched_period   = 5 * 1000 * 1000,  // 5ms period
};
syscall(SYS_sched_setattr, 0, &attr, 0);
```

SCHED_DEADLINE은 CFS 위에 있는 별도 클래스다. 데드라인 태스크는 항상 CFS 프로세스보다 먼저 실행된다. 잘못 설정하면 일반 프로세스가 완전히 굶주릴 수 있어서 `sched_rt_runtime_us` 제한이 있다.

## 실전 체크포인트

```bash
# 현재 스케줄러 통계 확인
cat /proc/schedstat

# 특정 프로세스 스케줄 정보
cat /proc/<PID>/sched

# 런큐 길이 실시간 모니터링
sar -q 1 5
```

CFS는 완벽한 스케줄러가 아니다. 설계 목표가 "공정함"이지 "최소 레이턴시"나 "최대 처리량"이 아니다. 시스템 성격에 맞게 파라미터를 조정하는 것이 아키텍트의 역할이다.

Linux CFS 스케줄러 — 왜 게임 PC와 서버 성능이 다르게 느껴지는가

// COMMENTS

ON THIS PAGE