Scheduler Nice Design

이 문서에서는 새로운 Linux 스케줄러에서 개선되고 간소화된 nice-levels 구현에 대한 생각을 설명합니다.

좋은 수준은 Linux에서는 항상 매우 약했고 사람들은 좋은 +19 작업이 CPU 시간을 훨씬 덜 사용하도록 계속해서 우리를 괴롭혔습니다.

불행히도 이전 스케줄러에서는 구현하기가 그리 쉽지 않았습니다. (그렇지 않았다면 오래 전에 했을 것입니다.) 좋은 수준의 지원이 역사적으로 타임슬라이스 길이에 연결되어 있었고, 타임슬라이스 단위는 HZ 틱으로 구동되어 가장 작은 타임슬라이스가 1/HZ였습니다.

O(1) 스케줄러(2003년)에서 우리는 부정적인 좋은 레벨을 2.4에서 이전보다 훨씬 더 강하게 바꾸었고(사람들은 그 변화에 만족했습니다), 또한 선형 타임슬라이스 규칙을 의도적으로 보정하여 좋은 레벨 +19가 _정확히_1 jiffy가 되도록 했습니다. 더 잘 이해하기 위해서 타임슬라이스 그래프는 다음과 같습니다(치즈 아스키 아트 경보!):

                  A
            \     | [timeslice length]
             \    |
              \   |
               \  |
                \ |
                 \|___100msecs
                  |^ . _
                  |      ^ . _
                  |            ^ . _
-*----------------------------------*-----> [nice level]
-20               |                +19
                  |
                  |

그래서 누군가가 정말로 작업을 포기하고 싶다면, +19가 일반 선형 규칙보다 훨씬 더 큰 타격을 줄 것입니다. (ABI를 변경하여 우선순위를 확장하는 해결책은 일찌감치 폐기되었습니다.)

이 접근 방식은 한동안 어느 정도 효과가 있었지만 나중에 HZ=1000에서는 1 jiffy가 1msec가 되어 CPU 사용률이 0.1%로 약간 과도하다고 느껴졌습니다. CPU 사용률이 너무 작기 때문에 과도한 것은 아니지만 너무 자주(밀리세컨당 한 번) 일정을 재조정하기 때문입니다. (그러면 캐시 등이 낭비됩니다. 기억하세요, 하드웨어가 더 약하고 캐시가 더 작기 때문에 사람들은 +19에서 숫자 크런치 앱을 실행하고 있었습니다.)

그래서 HZ=1000의 경우 우리는 nice +19를 5msec로 변경했습니다. 왜냐하면 그것은 적절한 최소한의 세분성으로 느껴졌기 때문입니다. 그리고 이것은 5%의 CPU 사용률로 해석됩니다. 그러나 nice +19에 대한 기본적인 HZ 민감 속성은 여전히 남아 있었고, 우리는 nice +19가 CPU 사용률 측면에서 너무 _약하다는 불만을 단 한 번도 받지 못했고, 우리는 그것이 너무 _강하다는 불만을 (그래도) 받았을 뿐입니다. :-)

요약하자면, 우리는 항상 좋은 수준을 더 일관성 있게 만들기를 원했지만, HZ와 Jiffies의 제약 조건과 타임슬라이스와 세분화에 대한 고약한 설계 수준 결합은 실제로 실행 가능하지 않았습니다.

리눅스의 훌륭한 수준 지원에 대한 두 번째 불만은 (위 사진에서 볼 수 있듯이) 원본에 대한 비대칭성, 즉 좋은 수준의 동작이 _절대_좋은 수준에도 의존하는 반면, 좋은 API 자체는 근본적으로 "상대적"이라는 사실입니다:

 

int nice(int inc);

asmlinkage long sys_nice(int increment)

(첫 번째는 glibc API, 두 번째는 syscall API입니다.) 'inc'는 현재 nice 레벨과 상대적입니다. bash의 nice 명령과 같은 도구는 이 상대적인 API를 반영합니다.

 

이전 스케줄러의 경우, 예를 들어 +1로 nice 작업을 시작하고 +2로 다른 작업을 시작한 경우 두 작업 간의 CPU 분할은 상위 셸의 nice 수준에 따라 달라집니다. -10이 nice인 경우 CPU 분할은 +5 또는 +10인 경우와 다릅니다.

리눅스의 좋은 수준 지원에 대한 세 번째 불만은 부정적인 좋은 수준이 '충분히 주먹구구식'이 아니기 때문에 많은 사람들이 SCHED_FIFO와 같은 RT 우선 순위에서 오디오(및 기타 멀티미디어) 앱을 실행해야 한다는 것이었습니다. 그러나 이로 인해 다른 문제가 발생했습니다: SCHED_FIFO는 기아에 대한 증거가 아니며 버그가 많은 SCHED_FIFO 앱도 시스템을 영원히 잠글 수 있습니다.

v2.6.23의 새 스케줄러는 다음 세 가지 유형의 불만 사항을 모두 해결합니다:

첫 번째 불만 사항을 해결하기 위해 스케줄러를 '타임 슬라이스' 및 HZ 개념에서 분리하고(그리고 세분화는 좋은 수준과 별도의 개념으로 만들어졌습니다), 새로운 스케줄러 nice +19 태스크를 사용하면 이전 스케줄러에서 얻은 가변 3%-5%-9% 범위 대신 HZ 독립 1.5%를 얻을 수 있습니다.

(좋은 수준이 일관되지 않음) 두 번째 불만 사항을 해결하기 위해 새 스케줄러는 좋은 수준(1)이 절대적인 좋은 수준과 상관없이 작업에 동일한 CPU 사용률 효과를 갖도록 합니다. 따라서 새 스케줄러에서 좋은 +10 태스크와 좋은 11 태스크를 실행하면 좋은 -5 태스크와 좋은 -4 태스크를 실행하는 것과 동일한 CPU 사용률이 "분할"됩니다. (하나는 CPU의 55%를 차지하고, 다른 하나는 45%를 차지합니다.) 이것이 좋은 수준이 "배수"(또는 지수)로 변경된 이유이며, 따라서 어떤 좋은 수준에서 시작하든 상관없이 '상대적 결과'는 항상 동일합니다.

세 번째 불만 사항(부정적인 좋은 수준이 충분히 "펀치"하지 않고 오디오 앱을 더 위험한 SCHED_FIFO 스케줄링 정책 하에서 실행해야 한다는 것)은 새 스케줄러가 거의 자동으로 해결했습니다. 부정적인 좋은 수준이 더 강해진 것은 좋은 수준의 재보정된 동적 범위의 자동 부작용입니다.