티스토리 뷰

Study/Architecture

[Architecture] Processes

생각많은 소심남 2016. 7. 7. 00:13

 예전에 Process가 뭐냐는 이름으로 포스팅을 한적이 있다.

2014/08/29 - [About Study/OS] - [Process] What is a process?


다룬지도 한참되었기도 하고 강의에 해당 주제로 하는게 있어 다시 정리해보고자 한다.


 Process란 현재 프로그램이 동작하는 개념 그 자체를 말한다. 프로그램이 돌아가면서 사용되는 CPU, MMU, 혹은 input/output device 로부터 resource를 할당받아서 돌아가는 주체이다. 각 process는 state 라는 것을 가지고 있는데, 사용자는 이 state를 보면서 현재 process의 상태를 확인할 수 있다. 물론 state라는 단어 자체가 상태를 의미하긴 하지만 process state에는 보통 아래와 같은 내용들이 포함되어 있다.

 - register나 program counter에 들어있는 값과 같은 CPU의 하드웨어적인 상태.

 - 이전 포스트에서 다뤘던 code, stack, heap 등을 포함한 process의 virtual address space내의 contents

 (보통 context라고 하고, resident 상태에 따라서 이런 값들이 실제 memory에 있을 수도 있고, 혹은 HDD같은 secondary storage에 담겨있을 수 있다.)

 - MMU의 하드웨어적인 상태

 ( 다르게 말하면 page map, 지난 포스트 내용을 빌자면 page directory register와 context number 들을 통한 값들이 포함된다.)

 - Virtual I/O device로부터 받은 정보들

( 예를 들어 file system에서 file read/write를 하는 것이나 keyboard, mouse action 같은게 다 포함된다.) 


그리고 여러 process 중 가장 중요하고 정보를 많이 가진 개체가 있는데, 그게 바로 OS Kernel이다. OS 는 자기 자신도 process 이면서 자신 내부에서 돌아갈 process 에 대해서도 관리를 한다. 예를 들어 파일속에 있는 데이터를 읽어온다던가 네트워크를 형성한다던지, 심지어는 우리가 보고 있는 Windows 화면을 띄우는 것 까지도 process이며, OS kernel은 이런 process 들이 주기적으로 실행될 수 있도록 관리를 한다. 

 이제 실행되고 있는 process가 다른 process로 전환될때를 생각해보자. 앞에서 언급한 것처럼 process는 가지고 있는게 매우 많고, 실행되기 위해서도 필요한 요소들이 매우 많다. 따라서 전환을 위해서는 현재 구동되고 있는 process의 state를 저장하고 원하는 data를 load시켜야 한다. 이 정보들이 physical memory안에 이미 상주해 있을 수도 있고, 혹은 secondary storage에서 다양한 kernel data structure의 형태로 저장되어 있을 수 있다. 

 여기서 이제 각 process를 virtual machine, 즉 하나의 computer system이라고 생각해보자. 우리가 생각하는 키보드 마우스 모니터가 달린 physical 한 machine이 아닌, 그래도 내부의 정보를 이용해서 어떤 program을 실행시키는 가상의 기계라고 말이다. 그러면 바로 앞에서 언급한 것처럼 process가 전환된다는 개념도 어떻게 보면 virtual machine이 전환되는 것이라 생각하면 되겠다. 당연히 process도 여러개가 동시에 구동되는 것처럼, virtual machine도 하나의 실행되는 개체 내에서 적절한 배분을 통해 골고루 실행되는 것이 좋을 것 같다. 이게 바로 virtual machine의 궁극적인 목표이다. 하나의 physical system에서 여러 개의 큰 process, 예를 들어서 OS Kernel을 실행시키는 것이라고 보면 된다.


 우리에게 주어진 것들은 모두 physical 요소들이다. CPU나 MEM는 빠질 수 없는 컴퓨터의 구성 요소가 될 것이고, Timer는 좀 의아할수도 있는데, 여러 개의 virtual machine을 골고루 수행하기 위해서는 그 주기를 계산하기 위한 timer가 꼭 필요하다. 거기에 비휘발성 데이터를 저장할 수 있는 Disk와 I/O, Display 요소들은 virtual machine을 구성하기 위해 꼭 필요한 물리적 요소들이다.



 이 물리적 요소들을 관장할 OS Kernel이 바로 위에 상주해있고, 그 위로 Virtual machine p1이 올라가게 된다. 위 그림에서 빨간색으로 표시되어 있는 부분이 모두 virtual device 들이다. 물론 physical device와 직접적으로 연결되어 있지 않지만 사용자의 입력은 OS kernel을 거쳐서 Virtual machine의 각 device들에게 전달된다. 예를 들어 VMWare나 Virtual Box를 써본 사람이라면 알겠지만 사용자가 Virtual machine에서 마우스를 움직이면 mouse cursor가 똑같이 따라간다. 이처럼 사용자 input이 그대로 virtual machine에게 전달되어서 움직이게끔 했기 때문에 가능한 것이다. 이처럼 물리적인 형태가 존재하지 않을뿐이지 일반 시스템의 형태와 동일하게 구성되어 있다. 

 사실 이게 가능한 이유는 virtual machine 마다 physical device와 연결되어 있는 OS kernel과 데이터를 주고받을 수 있는 통로가 존재하기 때문이다. 그 통로가 바로 Supervisor Call (SVC)이다. 이 SVC를 통해서 virtual machine은 OS에게 원하는 정보와 명령을 전달할 수 있다.


 앞에서 언급했던 바와 같이 모든 virtual machine은 각각의 virtual device들과 SVC들을 가지고 있다. 그런데 생각해보면 말이 안될 수 있다. physical device들이 이렇게 각 virtual machine 별로 있는데, physical device들은 각각 한개씩만 존재한다. 그럼 만약 여러개의 virtual machine이 동일한 작업을 수행하고자 하는 경우라면 어떡할까? 우리 눈에는 안보이겠지만 virtual machine들도 내부적으로 주기적으로 switching된다. 이런 걸 일종의 time-sharing system이라고도 하는데, 시간적인 개념으로 잘개 쪼개 각각 process가 구동되는데 쓴다는 것이다. 그리고 이 주기를 짧게 하면 사용자가 해당 process가 멈췄다는 느낌을 받지 않고 여러개의 process가 동시에 구동되는 것처럼 느끼게 해주게 된다. 이 개념을 조금더 살펴보면,

Process #0가 정상적으로 user-mode로 실행되고 있는 상태에서 아래와 같이 

만약 interrupt가 발생한다면 CPU는 process #0의 동작을 멈추고 다음으로 실행될 instruction의 위치(PC+4)를 XP register에 저장한 후, kernel mode로 진입하게 된다.

3번에서 CPU는 kernel mode에 진입하면서 process #0의 state들을 저장하고 넘어갈 process #1에 대한 state를 load하게 된다.

이후에 process #1으로 return 되고 난후 그 작업을 계속 실행하게 된다. 보통 process가 한개라면 interrupt가 발생한 후 kernel mode에서 interrupt exception이 처리되고 다시 원래 process로 돌아가겠지만, 지금은 process #1로 return 된다는 점에서 조금 다른 부분이 있다. 만약 이 interrupt가 timer관련 interrupt라고 하면, 지금 우리가 언급한 작업은 주기적으로 timer interrupt가 발생하면서 process들끼리 계속 교환되는 동작을 묘사한 것이다. 이게 곧 CPU를 multiplex한 방법이자 앞에서 언급한 time-sharing의 개념이다.

 간단하게 Process의 개념과 여기서 조금더 발전한 Virtual machine의 동작 형태를 살펴보았다.

'Study > Architecture' 카테고리의 다른 글

[ARM] Registers on the ARM Cortex M4  (0) 2017.02.10
[Architecture] MMU improvements  (0) 2016.07.06
[Architecture] Contexts  (0) 2016.07.05
[Architecture] Building the MMU (2)  (1) 2016.07.04
[Architecture] Building the MMU (1)  (0) 2016.06.30
[Architecture] Page faults  (0) 2016.06.29
[Architecture] Basics of Virtual Memory (2)  (0) 2016.06.26
댓글