Linux CFS는 2018 4.9 커널에서 프로세스와 스레드를 어떻게 공정하게 예약합니까?

Linux CFS는 2018 4.9 커널에서 프로세스와 스레드를 어떻게 공정하게 예약합니까?

Linux 스케줄러는 계속 발전하고 있습니다. 오늘날의 커널은 프로세스와 스레드를 어떻게 예약합니까? 자동 그룹화가 필요합니까?

이전 유사한 스택 오버플로 질문수년이 지났어요그리고 오래된 것일 수도 있습니다.

2018년의 기본값은 다음과 같습니다.완전히 공정한 스케줄러(만성 피로 증후군) O(1) 또는 다른 스케줄러 대신.

Linux의 경우 일부 문서에서 운영 체제 저글링을 언급합니다.무관심하게 표현한다프로세스또는철사프로세스 구분 또는 명확한 구분이 없지만 일정 관리에 중요합니다.

명확하게 말하면 프로세스는 프로그램을 실행하고 다중 스레드일 때 하나 이상의 스레드를 생성할 수 있습니다. 나에게 차이점은 프로세스의 모든 스레드가 동일한 가상 주소 공간을 사용한다는 것입니다. 그러나 CPU에 대한 스케줄링의 경우 이러한 구별은 부적합합니다.

P 프로세스를 실행하면 각각 다른 Tp 수의 스레드가 있습니다.

  • 프로세스 공정성: 여러 스레드가 있는 프로세스가 모든 리소스를 소모하지 않고 스레드가 1개인 프로세스를 압도하지 않도록 하는 방법은 무엇입니까? 공식적인 공정한 스케줄링은 프로세스 P가 CPU 자원의 1/Pth를 획득하고 이 1/Pth를 P 1/(Pth*Tp)의 각 스레드에 균등하게 분배해야 함을 의미합니다. CFS가 기본적으로 이를 보장합니까?
  • 자동 그룹화가 필요합니까?? 자동 그룹화를 통해 프로세스는 작업 그룹을 함께 예약할 수 있습니다. 기본적으로 한 세트가 있지만 두 번째 스레드를 스핀하면 CPU가 1/2이 되고, 10을 스핀하면 각 스레드 세트는 1/10이 됩니다. 간단합니다(갱 파견 참조).
  • 멀티코어: 저는 멀티 코어 로드 밸런싱과 코어 간 프로세스 마이그레이션에 대한 고려 사항에 그다지 관심이 없어 답변이 혼란스럽습니다.

실험 결과:CFS는 프로세스 간에 공평한 것 같습니다.

4.9.27에서 소규모 프로세스와 여러 스레드가 있는 장기 실행 프로세스의 런타임을 모니터링하려고 합니다. 내 커널의 스케줄러는 스레드가 아닌 프로세스별로 일정을 잡는 것 같습니다. 따라서 작은 프로세스는 공정하게 처리되어 CPU의 50%를 차지합니다. 2개의 장기 실행 프로세스를 사용하면 33%를 얻습니다. 감속은 각각 2.2배와 3.4배입니다.

이 커널은 자동 그룹으로 컴파일되지 않은 것 같습니다. setid()는 작동하지만 아무 것도 하지 않는 것 같고 /proc/*/autogroup이 존재하지 않으므로 CFS를 사용할 때 자동 그룹을 사용하려고 합니다.~인 것 같다옳은 일을 하는 것은 비용이 많이 드는 일입니다. 그러나 일부 다른 데이터 포인트는 때때로 이러한 동작이 프로세스에 불공정하다는 것을 나타내는 것 같습니다.

부가 질문

하나의 프로세스가 다른 모든 프로세스보다 더 자주 실행되도록 보장하는 방법이 있습니까? LD_LIBRARY_PATH 사용으로 인해 실시간으로 승격시킬 수 없을 것 같습니다. 그럼에도 불구하고 시스템을 모니터링하기 위해 /proc을 읽기 때문에 시스템 용량이 심각하게 초과되면 여전히 심각한 지연이 발생하는 경우가 있다고 생각됩니다.

감사해요!

답변1

SCHED_OTHER 스케줄링 정책에 따라 동일한 코어에서 동시에 실행되는 CPU 바인딩된 작업에 대한 답변(공정성 고려 사항이 io 바인딩 작업보다 관찰하기 쉽기 때문)(유일한 진정한 시간 공유 스케줄링 정책이므로)


프로세스(UNIX 시스템에서 상속된 용어의 의미에서)는 예약 엔터티가 아닙니다. 스레드만 존재하며 CFS는 상위 고려 사항에 관계없이 스레드를 예약합니다. man sched 인용:

   The thread to run is chosen from the static priority 0 list based
   on a dynamic priority that is determined only inside this list.
   The dynamic priority is based on the nice value (see below) and
   is increased for each time quantum the thread is ready to run,
   but denied to run by the scheduler.  This ensures fair progress
   among all SCHED_OTHER threads.

따라서 어떤 멀티스레드 애플리케이션이던 간에할 수 있는여러 번 입증되었듯이 동일한 코어에서 동시에 실행되는 단일 스레드 애플리케이션보다 전역적으로 더 많은 CPU 성능을 얻습니다.(§3부터 읽으세요)기간. 1


Linux 커널 제어 그룹 지원:

적절하게 구성된 경우(CONFIG_CROUPS=y) 커널은 작업을 그룹화하는 기능을 제공합니다. 추측해 보세요.태스크 포스! :-P 또한 다른 프로그램(데이터 구조 채우기)(예: 메모리 컨트롤러 및 물론 CFS)에 이러한 그룹화에 대해 알립니다.

그런 다음 적절하게 구성된 경우(CONFIG_CGROUP_SCHED=y) CFS는 모든 기존 작업 그룹 간의 공정성을 보장하기 위해 CPU 대역폭 할당을 제어합니다. 2

이 경우(CONFIG_CROUPS=y && CONFIG_CGROUP_SCHED=y) 위 명령문을 다시 공식화할 수 있습니다.

어떤 멀티스레드 애플리케이션이든 상관없습니다.~ 할 것이다단일 스레드 애플리케이션보다 전체적으로 더 많은 CPU 성능을 얻습니다.동일한 작업 그룹에 속해 있음그러나 공존하는 다른 작업 그룹에 할당된 CPU 성능 이상은 아닙니다.


자동 그룹화

작업을 그룹화하려면 명시적인 사용자 작업(초기 특정 시스템 구성이 아닌 경우)이 필요하고 대부분의 일반 데스크탑 사용자는 이 작업에 신경쓰고 싶지 않지만 사용자가 자신의 세션에서 수행하는 작업에 관계없이 데스크탑이 응답성을 유지하기를 원하기 때문에 커널은 세션별로 작업 그룹을 자동으로 생성하고 채우는 기능을 제공합니다.
CONFIG_SCHED_AUTOGROUP이 설정된 경우 각 세션마다 작업 그룹이 생성되고 이 세션에서 시작된 모든 작업은 이 작업 그룹에 속합니다 . 4


당신의 부가 질문("한 프로세스가 다른 모든 프로세스보다 더 자주 실행되도록 보장하는 트릭이 있습니까?") SCHED_NORMAL 스레드를 예약하는 데 사용되는 알고리즘이 결정적이며 가능한 최상의 결과를 보장하므로 거의 비합리적인 것처럼 보입니다.정격. 이 경우 달성을 기대할 수 없습니다.“더 많은 규칙성”, 또는 그 이하정격일부 스레드의 경우 인터럽트를 원하지 않는 한...정격.
그러나 스레드를 다소 자주 예약할 수도 있습니다. 이 경우 적절한 값을 조정하면 됩니다.


1:은혜의 말씀: 별도의 관리 없이 chromium -j64 빌드 시 출시된 비디오를 즐길 수는 없습니다 :-P

2: 안돼! 구성 태그에서 제안하는 것과는 달리 CFS는 작업 그룹 예약을 시작하지 않습니다. 여전히 스레드를 예약하지만 선택할 때 동일한 작업 그룹에 속하는 다른 모든 스레드에 할당된 CPU 시간의 합계를 고려하여 다른 기존 작업 그룹에 속하는 스레드에 할당된 총 시간을 초과하지 않도록 합니다.

삼:은혜의 말씀: 크롬 버전과 비디오 플레이어가 동일한 작업 그룹에 속하지 않도록 특별한 주의를 기울이면 코어 2에서도 make -j64와 병렬로 비디오를 실행하는 것이 좋습니다. 그렇지 않다면 make -j64와 병렬로 실행하는 이 비디오를 좋아할 것입니다. ...1로 이동 :-P

4:은혜의 말씀: 크롬 버전과 플레이어를 서로 다른 두 세션에서 실행하는 데 주의를 기울였다면 재미있게 즐겨보세요. 동일한 세션으로 시작하면... 1 :-P로 이동합니다.

관련 정보