긴 계산과 짧은 대화형 작업을 함께 실행합니다. Round Robin의 time quantum을 줄이면 응답성과 문맥 교환 비용이 어떻게 달라지나요?

Round Robin의 quantum은 한 작업이 선점되기 전 받을 수 있는 최대 실행 시간입니다. quantum을 줄이면 runnable 작업이 다시 차례를 받을 때까지의 대기 시간이 짧아져 대화형 요청의 첫 응답이 좋아질 수 있습니다. 그러나 선점마다 레지스터 저장·복원, 스케줄러 실행, 캐시 지역성 손실이 생기므로 너무 작으면 실제 계산보다 전환에 쓰는 시간이 커집니다. quantum을 키우면 전환 비용은 줄지만 긴 CPU 작업이 짧은 요청을 오래 막아 응답성이 나빠집니다. 이 균형을 측정으로 판단합니다.

작업 종류에 따라 해석합니다

CPU-bound 작업은 quantum을 대부분 소비하므로 quantum 변화가 선점 횟수에 직접 영향을 줍니다. I/O-bound 작업은 quantum이 끝나기 전에 블로킹될 수 있어 매번 같은 선점 비용을 만들지 않습니다. 짧은 대화형 작업이 quantum 안에 완료되면 빠르게 끝날 수 있지만, 실행 가능한 작업 수가 많으면 한 바퀴를 기다리는 시간은 대략 작업 수와 quantum에 비례해 늘어납니다. 우선순위 큐가 함께 있다면 모든 작업이 공평하게 Round Robin을 적용받는다고 가정하지 말고 실제 스케줄러의 그룹·우선순위 규칙을 확인해야 합니다.

적절한 값은 전환 비용보다 충분히 크면서 사용자 응답 예산보다 한 바퀴 대기가 길어지지 않는 범위에서 찾습니다. 단순히 CPU utilization이 높아지는 값을 고르지 않고 runnable 수, 자발적·비자발적 전환, 첫 응답·완료 시간, 짧은 작업 p99와 긴 작업의 기아 여부를 비교합니다. quantum을 줄였는데 p99가 나빠진다면 캐시 miss와 스케줄러 비용, 반대로 키웠는데 짧은 요청이 밀린다면 한 번에 오래 실행되는 CPU 작업을 조사하겠습니다.

운영체제와 부하를 함께 봅니다

교과서의 단일 quantum을 현재 OS가 애플리케이션별로 직접 설정할 수 있다고 단정하지 않습니다. 실제로는 우선순위, cgroup, 실행기, CPU affinity가 효과를 함께 결정할 수 있습니다. 테스트는 CPU 작업만 있는 경우, I/O 작업이 섞인 경우, runnable 수가 증가하는 경우, burst가 발생하는 경우를 나눕니다. 변경 전후의 처리량·p99·전환 비율·캐시 miss를 확인해 숫자 자체가 아니라 사용자가 기다리는 원인을 줄였는지 판단하겠습니다.

runnable 작업이 4개이고 quantum이 5ms라면 한 작업은 최악의 경우 약 15ms의 다른 CPU 시간 뒤에 다시 차례를 받습니다. 작업이 400개면 같은 quantum에서도 한 바퀴가 훨씬 길어집니다. I/O 작업은 quantum을 다 쓰기 전에 잠들 수 있으므로 CPU 작업과 동일한 선점 비용을 만들지 않습니다. 실제 스케줄러의 우선순위와 wake-up 규칙이 quantum보다 큰 영향을 주는 경우도 있어 먼저 확인하겠습니다.

실행기의 yield나 batch 상한은 OS quantum과 다른 층의 제어입니다. 실행기가 한 callback을 오래 붙들면 OS가 공정하게 선점해도 애플리케이션 큐에서 짧은 작업이 막힐 수 있습니다. quantum 후보마다 전환·cache miss·첫 응답·완료 시간·짧은 작업 p99를 측정하고, 변경이 가능한 OS 값인지 실행기 값인지 명시해 조정하겠습니다.

예를 들어 runnable 작업이 4개이고 quantum이 5ms라면 한 작업이 다음 차례까지 기다리는 CPU 시간은 이상적으로 최대 약 15ms에 전환 비용을 더한 값입니다. runnable 작업이 400개면 같은 quantum도 반응성 보장이 되지 않습니다. 따라서 quantum만 고정해 사용자 p99를 약속하지 않겠습니다.