[OS] Process Description and Control IV (Mode Switch, Context Switch)

Mode Switch

Mode Switch는 단순히 Kernel Mode와 User Mode에 대한 전환이다. 따라서 Mode만 바뀌는 것이다. Mode만 바뀌고 있는 것이기 때문에 User에서 Kernel로 넘어갔다고 하더라도 Process의 전환이 일어난 것은 아니다. 예를 들어 Process A를 수행하고 있는데 System Timer Interrupt가 발생했다고 하자. 이 Interrupt는 필연적으로 User Level에서 Kernel Level로 전위가 일어나자민 여전히 Process A는 실행중이다. Process를 수행하는 환경만 바뀐 것이지 Process 자체가 바뀐 것은 아니다. 따라서 Mode Switch의 비용은 Stack에 save/load 하는 등의 Overhead밖에 들지 않는다.

Context Switch

Context Switch는 흔하게 Process Switch라고도 불린다. 그러나 Context Switch라는 말이 더 많이 사용되는 것 같아 이 용어로 사용하겠다. 이는 말 그대로 Process의 전위가 일어난 것이다. 즉 Running되고 있던 Process는 다른 State로 바뀌고 다른 Process가 Running State로 바뀌는 것이다. Context Switch는 따라서 다른 Process를 처리하겠다는 것이다. 그러나 Context Switch를 수행하기 위해서는 많은 비용이 발생한다. Context Switch가 발생한다고 OS가 지시하면 그 즉시 현재 Process의 PCB를 업데이트 해야한다. 이때 Current State가 바뀌게 된다. Blocked Status, Ready Status 등 적당한 곳으로 배치받는다. 그러면 업데이트 된 PCB를 해당 State의 Wait Queue에 push하게 된다. 그 후에는 Scheduling Algorithm에 의해 다음에 수행할 새로운 Process를 찾게 된다. 이제 선택된 Process의 PCB를 Running State로 업데이트 한다. 문제는 이때 Cache의 Hit Ratio가 급격하게 떨어진다. Cache는 이미 이전의 Process에 의해 최적화가 었지만, 이제는 완전히 새로운 Process가 들어오는 것이기 때문에 Cahce의 최적화를 다시 해야한다. 이러한 비효율적인 Cache의 상태를 Cache Pollution이라고 부른다. 마찬가지로 뒤에서 다룰 것이지만 Memory 관리를 위한 TLB역시 업데이트 해야한다. 마지막으로, 선택된 Process의 이전 Context를 해당 PCB로 부터 Load해와야 한다. 따라서 Context Switch의 비용은 어마어마 하다고 할 수 있을 것이다. 

 

 사실상 Mode Switch는 Context Switch의 부분집합이라고 할 수 있을 것이다. Mode Switch의 빈도는 Context Switch보다 압도적으로 많다. 

위 그림을 기억하는가? 앞서서 사용했던 그림이지만 핵심은 Mode Switch는 정말 빈번하기 일어나고 있고, Context Switch는 또 자주 일어나지는 않는다. Timeout이 자주되기에 Mode Switch는 자주 나타나고 또한 다른 Interrupt, Exception, Sys Call들은 Mode Switch를 야기시킨다. 반면 Context Switch는 상대적으로 빈번하게 일어나지 않는다. 또한, 주목해야할 점은 Context Switch를 수행하기 위해서는 Mode Switch를 통해 Kernel Model Level에서 Context Switch가 일어나지만, Mode Switch가 필연적으로 Context Switch로 이어지는 것은 아니다. Scheduling 함수에 의해 이전과 같은 Process가 다시 선택을 받을 수도 있다. 따라서 Mode Switch가 Context Switch를 보장해주지는 못하지만, 필요조건이라는 것으로 생각하면 되겠다. 

Execution Model of OS

우리는 지금까지 OS를 수동적인 Entity로 바라보았다. Interrupt, Exception, Sys Call을 통해 수동적으로 동작하는 객체였다. 물론 Kernel에는 Daemon 등을 통해 별도의 thread를 만들어 능동적으로 활용할수 있겠지만, 어째뜬 OS는 수동적이라고 부를 수 있을 것이다. 그러면 OS가 어떤 방식으로 Execute되는지 바라보자.

첫째로 Nonprocess Kernel 방식이 있다. 이는 아주 전통적인 방식이며 Kernel을 별도의 Entity로 바라보았다. 전통적인 방식이기에 현대에서는 찾아보기는 힘들고 오래된 OS에서나 사용되는 방식이다. 두 번쨰는 Execution with User Process 방식이 있다. 이 방식은 현대 OS가 사용하고 있는 방식이다. Kernel은 User Process 내에서 같이 working하고 있다. 따라서 Kernel을 위한 별도의 Process Image가 필요하다. 마지막으로는 Process-Based OS 방식이 있다. 이 방식은 조금 더 유연한 설계로서 Kernel을 핵심 코드로만 구성하여 microlevel까지 구현할 수 있게 해준다. 이 방식에서는 이전의 Kernel의 Non-Critical한 기능들을 유저들에게 묘둘처럼 전달하여 Customize하는 방식이다. 

 

결국 Kernel이 User Process와 같이 일하게 되려면 Kernel은 Kernel만의 작업공간이 필요하다. 따라서 Process Image가 하나 더 필요하게 되는 것이다. 사실상 Kernel도 Program의 일종이다. 함수의 집합들로 구성되어 있기에 Process Image의 구성요소 중 하나인 Stack도 Kernel을 위해서 필요하다. 따라서 Process에는 두 개의 Stack 영역으로 구성되어 있다. User Stack은 User Code를 위한 stack이며 function 호출을 동적으로 관리하게 된다. Kernel Stack은 결국 Kernel도 그 내부에서 함수들을 복합적으로 호출해나가면서 Flow를 저장할 stack이 필요하게 된다. 당연하게도 이 Stack 영역은 각각의 Process마다 필요하다. Process마다 수행되는 Kernel Level 별 함수들이 다르기 때문이다. 이렇게 Stack 영역까지 이원화 시킨 이유는 Resource Protection 때문이다. 함부로 Kernel 코드에 접근할 수 없도록 Kernel Stack과 User Stack은 철처히 분리되어있다. 

Reference

William Stallings. (2018). Operating Systems: Internals and Design Principles (8th Edition): Pearson.