▲

GN⁺: Linux CPU 스케줄러에서 "게으른 선점" 구현을 위한 긴 여정

 (lwn.net)
3P by neo 2달전 | favorite | 댓글 1개
  • 커널의 CPU 스케줄러는 시스템 처리량과 응답 시간 간의 절충을 구현하는 여러 선점 모드를 제공함.
  • 2023년 9월, 스케줄링에 대한 논의에서 "게으른 선점(lazy preemption)"이라는 개념이 제안되었으며, 이는 커널의 스케줄링을 단순화하면서 더 나은 결과를 제공할 수 있음.
  • 이 개념은 한동안 조용했지만, Peter Zijlstra의 패치 시리즈로 다시 등장함.

현재 커널의 선점 모드

  • PREEMPT_NONE: 실행 중인 작업이 시간 슬라이스를 소진했을 때만 선점이 허용됨.
  • PREEMPT_VOLUNTARY: 필요할 경우 커널 내에서 선점이 가능한 많은 지점을 추가함.
  • PREEMPT_FULL: 스핀락이 걸린 경우를 제외하고 거의 모든 지점에서 선점이 가능함.
  • PREEMPT_RT: 대부분의 다른 것보다 선점을 우선시하며, 대부분의 스핀락 코드도 선점 가능하게 만듦.

게으른 선점의 도입

  • 게으른 선점 패치는 새로운 플래그 TIF_NEED_RESCHED_LAZY를 추가하여 즉시가 아닌 어느 시점에 리스케줄링이 필요함을 나타냄.
  • 게으른 선점 모드(PREEMPT_LAZY)에서는 대부분의 이벤트가 이 새로운 플래그를 설정하며, 커널에서 사용자 공간으로 돌아갈 때 두 플래그 중 하나가 설정되면 스케줄러 호출이 이루어짐.
  • 이 변경의 결과로, 게으른 선점 모드에서는 커널의 대부분의 이벤트가 현재 작업을 선점하지 않게 됨.

cond_resched() 제거

  • 이 작업의 최종 목표는 PREEMPT_LAZY와 PREEMPT_FULL 두 가지 비실시간 모드만 남기는 것임.
  • 게으른 모드는 PREEMPT_NONE과 PREEMPT_VOLUNTARY 사이의 위치를 차지하며, 이 두 모드를 대체함.
  • 현재는 cond_resched() 호출이 남아 있으며, PREEMPT_NONE 및 PREEMPT_VOLUNTARY 모드가 존재하는 한 필요함.

GN⁺의 정리

  • 게으른 선점은 커널의 스케줄링을 단순화하고 예측 가능한 지연 시간을 제공하는 데 기여할 수 있음.
  • 이 작업은 커널의 크기를 줄이고 코드를 간소화하는 데 도움이 될 수 있음.
  • 게으른 선점은 PREEMPT_VOLUNTARY와 유사한 처리량을 제공하지만, 더 많은 테스트와 최적화가 필요함.
  • 유사한 기능을 가진 다른 프로젝트로는 FreeBSD의 ULE 스케줄러가 있음.
▲
neo 2달전  [-]
Hacker News 의견

  • 게으른 선점 작업의 최종 결과는 커널이 더 작고 단순해지면서 예측 가능한 지연 시간을 제공하는 것임. 이는 코드 전반에 스케줄러 관련 호출을 뿌릴 필요 없이 더 나은 해결책으로 보임. 그러나 이를 달성하는 데 시간이 걸릴 것임.

    • EEVDF처럼 현 상태를 단순화하고 개선하는 것임. 더 나은 해결책은 없을 것임.

  • 높은 수준의 선점은 시스템이 이벤트에 더 빠르게 반응할 수 있게 함. 마우스 움직임이나 원자로의 "임박한 붕괴" 신호와 같은 이벤트에 빠른 반응은 더 만족스러움. 그러나 높은 수준의 선점은 시스템의 전체 처리량에 영향을 줄 수 있음. CPU 집약적인 작업이 많은 워크로드는 가능한 한 방해받지 않는 것이 유리함. 더 빈번한 선점은 더 높은 잠금 경합을 초래할 수 있음. 그래서 다양한 모드가 존재하며, 최적의 선점 모드는 워크로드에 따라 다를 것임.

    • 왜 선점 수준이 특정 이벤트의 속성이 아닌 전역 모드의 속성인지 궁금함. 일부 이벤트는 다른 이벤트보다 낮은 지연 시간으로 처리되어야 함.

  • 현재 커널은 한 작업이 다른 작업을 위해 선점될 수 있는 시기를 조절하는 네 가지 모드를 가지고 있음.

    • 커널 작업, 사용자 작업 또는 둘 다에 관한 것인지 궁금함.

  • 링크된 스레드에서 패치와 관련된 숫자를 찾을 수 없음. 변경의 실제 잠재력을 알려줄 수 있는 예비 벤치마킹이 수행되었을 것임.

  • 스케줄러가 나머지 커널 코드와 얼마나 밀접하게 결합되어 있는지 궁금함.

    • 예를 들어, 선점에 전혀 신경 쓰지 않는 과학적 응용 프로그램을 위해 스케줄러를 대폭 단순화하고자 할 때, 이를 깔끔하고 모듈식으로 수행할 수 있는지, 그리고 어떤 이점이 있을지 궁금함.

  • 선점이 이벤트에 따라 적응할 수 있다면 좋겠지만, 모든 이벤트에 대해 이를 관리하는 것은 시스템 안정성을 해칠 수 있음. 이는 Tomba Finder와 같은 도구를 사용하여 리드 생성하는 것과 비슷함.

    • 정밀도(목표 리드)와 효율성을 균형 있게 유지하여 전체적으로 원활하게 작동해야 함.
답변달기