CPU 스케줄링

실행 중인 프로세스에게서 CPU 를 뺏을 수 있는지가 다릅니다.

현대 범용 운영체제는 모두 선점형입니다. 비선점이면 무한 루프에 빠진 프로그램 하나가 시스템 전체를 멈추기 때문입니다.

비선점이 나은 곳도 있습니다. 처리량만 중요한 배치 시스템은 교환 비용이 없는 쪽이 유리합니다.

흔한 실수: 선점을 "우선순위가 높으면 뺏는다"로만 설명하는 것. 시간 할당량이 끝나도 뺏습니다. 우선순위와 무관하게 공평하게 나누는 것도 선점입니다.

너무 크면 순서대로 처리하는 것과 같아지고, 너무 작으면 교환 비용이 실제 일을 잡아먹습니다.

기준은 문맥 교환 비용과의 비율입니다. 교환에 10마이크로초가 든다면 퀀텀이 100마이크로초일 때 10%를 교환에 쓰는 셈입니다. 보통 대부분의 작업이 한 퀀텀 안에 끝나도록 잡습니다.

리눅스는 고정 퀀텀 대신 목표 지연 시간을 두고 실행 가능한 프로세스 수로 나누는 방식을 씁니다. 프로세스가 많아지면 각자의 몫이 자동으로 줄어듭니다.

흔한 실수: 퀀텀을 작게 할수록 공평하다고 답하는 것. 공평해지지만 전체 처리량이 떨어져 모두가 느려집니다.

평균 대기 시간을 최소로 만드는 것이 증명돼 있습니다. 짧은 작업을 먼저 끝내면 뒤에서 기다리는 총 시간이 줄어듭니다.

A(10초), B(1초), C(1초) 세 작업으로 비교하면 이렇습니다.

실무에서 못 쓰는 이유는 두 가지입니다.

첫 번째는 과거 실행 시간으로 추정해 완화할 수 있고, 두 번째는 기다린 시간만큼 우선순위를 올려주는 방식으로 막습니다.

흔한 실수: 기아만 말하고 실행 시간을 모른다는 점을 빼는 것. 후자가 더 근본적인 제약입니다.

우선순위가 다른 여러 큐를 두고, 관측된 행동에 따라 프로세스를 옮기는 방식입니다.

이 규칙이 만드는 효과는 실행 시간을 미리 몰라도 짧은 작업 우선과 비슷하게 동작한다는 것입니다. 짧은 작업은 끝나기 전에 큐를 내려갈 일이 없어 빨리 처리되고, 긴 작업은 자연히 아래로 내려갑니다.

네 번째 규칙이 기아를 막습니다. 아래에서 오래 기다린 프로세스도 주기적으로 위로 올라와 실행 기회를 얻습니다.

흔한 실수: 마지막 규칙을 빼고 답하는 것. 그것이 없으면 긴 작업이 최하위에 갇혀 영원히 밀립니다. 그리고 짧게 쓰고 내려가는 작업의 우선순위를 유지하는 것이 대화형 응답성을 지키는 핵심입니다.