의문이 든 이유
Context Switch 개념에 대해 공부하다가 아래의 내용을 접했다.
User mode에서 Kernel mode로 가는 건 Context Switch가 상대적으로 overhead가 적은 작업이다. Context Switch 없이 CPU 수행 정보 등 context의 일부를 PCB(Process Control Block)에 저장하기 때문이다. 다만, Kernel mode에서 User mode로 갈 때 Context Switch 발생 시에는 그 부담이 훨씬 크다. Cache Memory를 flush 할 때 overhead가 매우 크기 때문이다.
왜 Context Switch가 발생할 때 overhead가 큰 것일까?
Context Switch란?
Context Switch(문맥 교환)는 운영 체제에서 여러 프로세스나 스레드가 CPU에서 실행되는 동안 발생하는 작업이다. 쉽게 말하자면, CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정이라고 생각하면 된다.
단, 여기서 주의할 점은 같은 프로세스간에 일어나는 모드 전환은 Context Switch라고 하지 않는다. 이때는 Context Switch 없이 모드 전환만 일어난다.
여담이지만, 이 개념을 이해하기 쉬운 이야기를 하나 해보겠다. 간혹 개발자들 사이에서 오가는 농담으로 "저 요즘 일할 때 Context Switch가 너무 많이 일어나서 정신이 없어요"라고 하는데, 이 의미가 바로 일하는 중간에 왔다 갔다 하는 경우(Context Switch)가 많아서 정신이 없다(Overhead)는 의미다. (이제 아는 체 하면서 농담을 해보자)
@livecycle.io
overhead가 큰 이유
Context Switch 발생 시, overhead가 큰 이유는 아래와 같이 요약해 볼 수 있다. 결론부터 말하자면 해야 할 일이 너무 많아진다는 것이다.
레지스터(register) 상태 저장 및 복원
Context Switch가 일어나면 현재 실행 중인 프로세스나 스레드의 레지스터의 상태(프로그램 카운터, 스택 포인터 등)를 저장하고, 다음으로 실행될 프로세스나 스레드의 레지스터 상태를 복원해야 한다. 쉽게 말하자면 다음에 실행될 프로세스를 위해 레지스터를 준비해 두고 '준비되었습니다~ 어서 오세요~' 하며 맞이해야 한다는 것.
메모리 상태 전환
현재 실행 중인 프로세스나 스레드의 메모리 주소 공간을 저장하고, 다음으로 실행될 프로세스나 스레드의 메모리 주소 공간을 로드해야 한다. 이것은 페이지 테이블과 같은 메모리 관리 구조의 전환이 포함되며, 자연스럽게 overhead가 커지기 마련이다. 이 또한 쉽게 말하자면 다음에 실행될 프로세스를 모셔올 테이블 좌석을 만들어 두어야 한다는 것이다.
캐시 무효화
CPU 캐시에 있는 데이터가 다른 프로세스나 스레드로 전환될 때는 무효화되어야 한다. 이는 '캐시 일관성'을 유지하기 위한 작업으로 overhead를 발생시킨다. 굳이 하지 않아도 될 일을, 문맥 교환이 일어날 때는 해야 하는 일이다.
스케줄링 비용
어떤 프로세스나 스레드가 다음에 실행될지 결정하는 스케줄링 알고리즘에 따라 오버헤드가 발생한다. 스케줄링 결정을 내리기 위한 CPU 시간과 리소스가 필요하다. 이 또한 문맥 교환이 일어나지 않았을 때는 굳이 하지 않아도 될 일이다.
입출력 작업
프로세스나 스레드가 입출력 작업을 수행 중일 때, I/O(입출력) 작업 완료를 기다리는 동안 다른 프로세스나 스레드로 전환할 수 있다. 입출력 작업을 위한 커널 호출 및 입출력 장치와의 상호 작용도 오버헤드로 작용할 수 있다.
요약하자면
Context Switch 발생 시, 위의 모든 작업들은 커널 모드에서 수행되며, 커널 모드와 사용자 모드 간의 전환이 오버헤드를 발생시킨다. 따라서 context Switch가 자주 발생하면 시스템의 성능에 부정적인 영향을 미칠 수 있으므로, 효율적인 스케줄링 및 컨텍스트 스위치 관리가 중요할 것이다.
참고 자료
•
더 많은 내용이 궁금하다면 개인적으로 정리한 TIL
개인적으로 정리한 TIL