게으른 선점 작업의 최종 결과는 커널이 더 작고 단순해지면서 예측 가능한 지연 시간을 제공하는 것임. 이는 코드 전반에 스케줄러 관련 호출을 뿌릴 필요 없이 더 나은 해결책으로 보임. 그러나 이를 달성하는 데 시간이 걸릴 것임.
EEVDF처럼 현 상태를 단순화하고 개선하는 것임. 더 나은 해결책은 없을 것임.
높은 수준의 선점은 시스템이 이벤트에 더 빠르게 반응할 수 있게 함. 마우스 움직임이나 원자로의 "임박한 붕괴" 신호와 같은 이벤트에 빠른 반응은 더 만족스러움. 그러나 높은 수준의 선점은 시스템의 전체 처리량에 영향을 줄 수 있음. CPU 집약적인 작업이 많은 워크로드는 가능한 한 방해받지 않는 것이 유리함. 더 빈번한 선점은 더 높은 잠금 경합을 초래할 수 있음. 그래서 다양한 모드가 존재하며, 최적의 선점 모드는 워크로드에 따라 다를 것임.
왜 선점 수준이 특정 이벤트의 속성이 아닌 전역 모드의 속성인지 궁금함. 일부 이벤트는 다른 이벤트보다 낮은 지연 시간으로 처리되어야 함.
현재 커널은 한 작업이 다른 작업을 위해 선점될 수 있는 시기를 조절하는 네 가지 모드를 가지고 있음.
커널 작업, 사용자 작업 또는 둘 다에 관한 것인지 궁금함.
링크된 스레드에서 패치와 관련된 숫자를 찾을 수 없음. 변경의 실제 잠재력을 알려줄 수 있는 예비 벤치마킹이 수행되었을 것임.
스케줄러가 나머지 커널 코드와 얼마나 밀접하게 결합되어 있는지 궁금함.
예를 들어, 선점에 전혀 신경 쓰지 않는 과학적 응용 프로그램을 위해 스케줄러를 대폭 단순화하고자 할 때, 이를 깔끔하고 모듈식으로 수행할 수 있는지, 그리고 어떤 이점이 있을지 궁금함.
선점이 이벤트에 따라 적응할 수 있다면 좋겠지만, 모든 이벤트에 대해 이를 관리하는 것은 시스템 안정성을 해칠 수 있음. 이는 Tomba Finder와 같은 도구를 사용하여 리드 생성하는 것과 비슷함.
Hacker News 의견
게으른 선점 작업의 최종 결과는 커널이 더 작고 단순해지면서 예측 가능한 지연 시간을 제공하는 것임. 이는 코드 전반에 스케줄러 관련 호출을 뿌릴 필요 없이 더 나은 해결책으로 보임. 그러나 이를 달성하는 데 시간이 걸릴 것임.
높은 수준의 선점은 시스템이 이벤트에 더 빠르게 반응할 수 있게 함. 마우스 움직임이나 원자로의 "임박한 붕괴" 신호와 같은 이벤트에 빠른 반응은 더 만족스러움. 그러나 높은 수준의 선점은 시스템의 전체 처리량에 영향을 줄 수 있음. CPU 집약적인 작업이 많은 워크로드는 가능한 한 방해받지 않는 것이 유리함. 더 빈번한 선점은 더 높은 잠금 경합을 초래할 수 있음. 그래서 다양한 모드가 존재하며, 최적의 선점 모드는 워크로드에 따라 다를 것임.
현재 커널은 한 작업이 다른 작업을 위해 선점될 수 있는 시기를 조절하는 네 가지 모드를 가지고 있음.
링크된 스레드에서 패치와 관련된 숫자를 찾을 수 없음. 변경의 실제 잠재력을 알려줄 수 있는 예비 벤치마킹이 수행되었을 것임.
스케줄러가 나머지 커널 코드와 얼마나 밀접하게 결합되어 있는지 궁금함.
선점이 이벤트에 따라 적응할 수 있다면 좋겠지만, 모든 이벤트에 대해 이를 관리하는 것은 시스템 안정성을 해칠 수 있음. 이는 Tomba Finder와 같은 도구를 사용하여 리드 생성하는 것과 비슷함.