윈도의 커널과 스케쥴러 발전

쓰레드리퍼에 관한 글을 쓰다 보니 생각나서 읽은 걸 정리한다.

One Window Kernel

코어, 그리고 프로세서 수가 증가하면서 하나의 Ready Queue로는 병목 현상이 발생했다. 다중 작업에 대한 큐잉 딜레이 때문일 것이라 생각.

따라서 윈도 서버 2003부턴 프로세서당 하나의 Ready Queue를 갖는 구조로 변경되었다. 이는 다시 프로세서 당 여러 개의 Ready Queue를 갖는 구조로 진화하는데, 덕분에 스케쥴러가 Local Optimum Decision을 내릴 수 있게 되었다.

그러나 이는 모바일과 같은 저전력 환경에서 문제가 되었는데, 시스템의 쓰루풋이 높지 않은 상황에서 UI와 같은 높은 우선순위 쓰레드가 제대로 서비스되지 않아 끊김을 겪을 수 있기 때문이다. 따라서 윈도 8.1에선 Task Affinity를 위해 프로세서 당 여러 Ready Queue + 이 Ready Queue들 간 정보를 여러 프로세서 간 공유하는 하이브리드 모델로 바뀌었다.

사용자 각각이 터미널로 달라붙어 사용하는 공유 시스템을 생각해보자. 특정 사용자가 높은 부하의 작업을 처리 중이라고 한다면? CPU Time이 그 사용자에게 치중되어, 전체 사용자에게 서비스가 균등하지 않게 제공될 수 있다. 

시장의 프로세서 집적화가 고도화되면서 윈도 7에선 이에 대응하고자 64개의 Logical Processor를 하나의 Processor Group으로 묶기 시작했다. 내부적으론 Locality를 고려하여 같은 프로세서 상의 Logical Processor는 같은 Processor Group으로 묶이도록, 또한 이 Processor Group의 수는 가능한 적게 유지된다. 

그러나 기존의 방식으로는 프로세서 수의 증가만큼 전체 시스템 성능이 선형으로 증가하지 못했다. 이는 Dispatcher DB Lock을 두고 프로세서 간 경쟁으로 인한 병목 때문인데, 이 때문에 윈도 7에선 Object 당 Lock을 두어 성능 향상을 이뤘다. 

https://channel9.msdn.com/Shows/Going+Deep/Arun-Kishan-Farewell-to-the-Windows-Kernel-Dispatcher-Lock

윈도 10에서 도입한 CPU Sets은 특정 프로세스가 어떤 Processor Group에서 실행되어야 한다, 혹은 다른 프로세스는 이 Processor Group에서 실행되지 못하도록 파티셔닝 역할을 한다. 이는 시스템 보안 향상에 기여한다.