[OS] Mode switch & Process switch

G·2023년 3월 27일
0

OS

목록 보기
9/29
post-thumbnail

process switch가 일어나기 위한 기작을 mode switch와 PCB의 변화를 통해 알아본다.

Mode switch

컴퓨터의 자원 관리는 OS의 함수로 제공한다. 이 함수들은 process switch, 메모리 관리, system call, I/O device 접근 등을 제공한다.
일반 프로그램이 하드웨어 자원을 직접 사용하는 권한을 가지면 보안에 문제가 생긴다.

이를 해결할 방법은 유저 레벨의 프로그램이 돌아가는 상황의 상태를 user mode, 유저 모드가 I/O device에 접근해야하는 상황과 같은 OS의 함수의 도움을 받는 상태인 kernel mode로 관리하여 이를 해결할 수 있다.

이를 위해 Mode bit이 필요하다. 이는 하나 또는 두개의 bit으로, 현재 모드가 무엇인지 알려준다.

커널모드일 때만 사용할 수 있는 instruction의 예시는 다음과 같다.

  • interrupt 처리
  • instruction 중지
  • I/O 접근
  • 메모리 관리: base register 수정에 kernel이 필요함
  • mode bit 수정

이러한 instruction은 user mode에서 절대 사용할 수 없다.

mode switch는 user mode에서 kernel mode로 변경하는 것을 의미한다.
이는 현재 수행하는 process의 상태를 변경하는 것이 아니다.
이는 procedure call과 조금 비슷한데, kernel mode로 바뀐 이후 user mode로 변경될 때의 정보를 복원하기 위해, user mode의 정보를 control stack에 저장해야만한다.


(커널모드로 변경되는 원인이다.)

How kernel works

system call은 user level 프로그램에게 제공되는 interface로, file system, 메모리 할당, 프로세스 생성, 하드웨어 접근 등을 OS에게 요청하는 함수들이다. 이들은 프로그래밍 언어의 라이브러리에 mapping되어 형성되어 있으며, user mode에서 kernel 모드로의 mode switch를 발생시킨다.

이를 위해 내부 동기적 사건인 exception이 필요하며 하나의 프로세스에서 mode switch가 일어나는 것으로 process context상에 kernel이 존재한다 표현한다.

(반면에 interrupt는 현재 수행 중인 process와 관련이 없으며 이를 interrupt context라 표현한다.)

이 둘을 구분하는 이유는 interrupt context에선 큰 제약이 있다. 외부의 사건을 처리하기 위한 것이기 때문에, 효율성을 위해서 빠르게 처리해야한다. 이러한 이유로 interrupt context에선 sleep이 불가능하다.

kernel programming에선, in_interrupt() 함수를 통해 어느 context인지 구별한다.(true면 interrupt context이다.)

요약하여 user mode 상에선 user level의 프로그램을 수행하고, 커널 모드에선 interrupt context와 process context가 존재한다.

mode switch가 일어났을 때, kernel은 process switch를 발생할 수도 있다.(kerenl은 process switch의 필요조건이다.)


process P가 수행되다, timer interrupt로 mode switch가 일어나고 system call을 호출하여 process Q로 process switch가 일어나는 것을 확인할 수 있다.


위의 이미지는 유저모드에서 프로세스를 처리하다 커널모드로 모드 스위치가 발생했을 때의 모습이다. 왼쪽은 프로세스에서 커널모드로인해 프로세스 스위치가 발생한다. 반면에 오른쪽은 현재 수행 중인 process에서 그대로 커널 모드의 OS 함수를 수행한다.

process switch는 큰 overhead를 발생시키기 때문에 이를 발생시킬 이유가 없다.

e.g. process switch는 register context를 stack에 저장, cache의 정보가 바뀌기 때문에 miss rate 증가.

Kernel Stack

process context 상에 동작하는 OS 함수는 보안을 위해 process의 stack과 분리된 영역이 필요하다.


그렇다면 각각의 process는 두 개의 stack 영역이 필요하다.

  • User space stack
  • Kernel space stack
    user stack가 손상되어도 kerenl을 실행할 수 있다.

Process switch

process switch란 CPU가 수행하는 프로세스를 바꾸는 것을 의미한다.
mode switch가 일어난 이후, 커널이 process switch를 수행한다.

Via interrupt

만약 프로세스 A를 running 중에 block 되어 있던 프로세스에 interrupt가 발생하여 ready state로 바뀌었을 때 이 프로세스의 우선순위가 높다면 이 프로세스를 running 할지 결정해야한다. timer interrupt도 마찬가지로, time slice가 지났기 때문에, process switch가 발생햐아한다.

Via exception

프로세스 수행 중에, 예외가 발생해 프로세스를 종료해야 한다면, process를 종료상태로 변경하고 process switch가 발생한다.

Via system call

system call이 발생했을 때, 프로세스가 block될 수 있기 때문에 process switch가 발생할 수 있다.

Overhead

process switch가 발생할 때의 오버헤드를 알아보자.
process P와 Q를 변경한다 가정한다.

P: old process
Q: next process

Scheduler는 ready list에서 Q process를 가져와야 한다.(우선순위가 높다고 가정하자)
여기서 우선순위가 가장 높은 process를 찾아야하는데, 만약 프로세스가 수백, 수천개면 선형 자료구조일 경우 O(1)이 걸릴 것이다. 만약 리눅스와 같이 레드블랙트리로 구현되어 있다면 O(lg n)이 걸릴 것이다.

게다가 P와 Q의 상태(Running or blocked or ready) 정보를 변경해줘야 한다.(이는 PCB에 ㅈ장한다.) 즉 Q의 register context의 정보 모두 복원해야한다.

P도 PCB에 register context 정보를 저장해야한다.

P의 PCB를 대기 list에 추가해야할 것이다.

profile
열심히 안 사는 사람

0개의 댓글

Powered by GraphCDN, the GraphQL CDN