Daeseok's Blog

---

2.2 Process Life Cycle

 하나의 Process는 항상 실행 준비가 된 상태가 아니다. 때때로, Process는 외부 자원의 event 를 기다리고 있는 경우가 있다.(text 편집기에서 keyboard 입력 대기를 위한 경우). 이런 경우는 event(keyboard 입력)이 있을 때까지 process는 실행 될 수 없다. 

scheduler는 process들의 교체를 할때 시스템에 있는 모든 Process의 상태를 알고 있어야 한다. 이는 할일이 없는 process임에 불구하고 CPU 시간을 할당하는 일은 없어야 한다는 것이다. 시간 할당과 중요한 점은 각 process의 상태를 전환(예, 실행 상태 --> 대기상태)시키는 일이다. 예를 들어, 만약 하나의 process가 주변 장치의 data를 기다리고 있다면, scheduler는 process의 상태를 data가 도착할 때까지 실행 대기 상태로 변경해줘야 한다. 

하나의 process는 다음과 같은 상태를 가진다

□ Running -- Process는 실행 중이다. 

□ Waiting  -- Process는 실행 가능한 상태이지만 CPU 를 다른 process가 점유하여 사용 중이기 때문에 기다리는 상태이다. 이 상태의 process 는 scheduler에 의해 다음으로 실행 가능하다. 

□ Sleeping -- Process는 잠든(?) 상태이고, 수행될 수 없다. 외부 장치에 의해 data나 event를 기다리고 있는 상태이며, process가 event를 받기 전까지 scheduler가 선택할 수 없다. 

시스템은 하나의 process table에 그것들의 상태들과 관계없이(running, waiting, sleeping) 모든 process들을 저장한다. 그렇지만, sleeping 상태의 process는 scheduler가 실행 준비가 되지 않은 상태을 알고 있어야 함으로 특별히 "표시"를 해 둔다. 또한 외부 event를 기다리고 있는 process가 event가 발생시 적절한 시점에 깨어나 수행할 수 있도록 다수의 Queue 로 관리하고 있다. 

그림 2-2

실행 가능한 process의 queue에 다양한 상태전의를 알아보도록 하자. 하나의 process가 실행 가능한 상태이지만, 다른 process가 CPU를 점유하고 있는 상태라 CPU를 사용하기 위한 대기 상태이다. (이것의 상태는 "Waiting" 이다). 그것은 scheduler가 CPU 시간을 할당 할 때까지 "waiting" 상태로 남아있을 것이다. 일단 scheduler가 선택을 하면, 그 process의 상태는 "running"으로 바뀔 것이다. (그림 2-2 의 4번 전이)

scheduler가 process의 CPU 자원 사용을 그만 두게 하기로 결정했다면, 그 process의 상태는 "running"에서 "waiting"으로 변경된다. (그림 2-2 의 2번 전이), 그리고 새롭게 cycle을 시작한다. "Sleeping" 상태는 두 가지 경우가 있는데, 하나는 signal을 받아 방해(interrupt) 받을 수 있는 것과 그렇지 못한 것이다. 이시점에서는 sleeping의 경우의 수는 다루지 않는다. 

만약 process가 event를 기다리고 있는 상태라면, 그 process의 상태는 "running"에서 "sleeping" 상태로 변경된다. 하지만, sleeping 상태의 process는 바로 running 상태로 변경이 이루어지지 않는다. 일단 기다리던 event가 발생했을 경우, 그 process는 waiting(그림 2-2의 3번 전이)로 변경되고 다음 번 실행을 기다리게 된다. 

Program 실행이 종료되면(사용자가 application을 종료한 경우 등), process의 상태는 running에서 stopped로 변경된다(그림 2-2  에서 5번 전이)

위에 설명되지 않은 process의 특별한(?) 상태가 있는데, 그것은 "zombie" 상태이다. 이름에서도 알수 있듯이, process가 죽었지만 어찌된 영문인지 여전히 살아있는 상태로 보이는 것이다. 다시 말하면, 그 process들은 사용하던 자원(RAM, 주변장치의 연결 등)을 반납하고 다시는 실행될 수 없는 상태로 소위 죽은 것이다. 그렇지만 process table에 그것들을 위한 공간이 존재하기 때문에 살아있는 것처럼 보인다는 것이다. 

Process가 Zombie 상태로 들어가는 경우는, UNIX 시스템의 process 생성과 종료 구조에 관련되어 있다. 하나의 program가 종료하는 상태는 두 가지가 있다.. 한가지는, 다른 process나 사용자에 의해서 강제 종료되어지는 경우다.(이런 경우는 대게 SIGTERM 이나 SIGKILL signal을 종료대상 process에게 전달되어 이루어진다.-이는 process가 일반적으로 종료하는 경우와 동등한 효과를 가진다), 다른 한가지는, child process가 종료되는 시점에 parent process가 이미 wait4 시스템 콜을 실행하여 child의 종료상태를 parent가 받는 경우이다. 결국 parent process가 child의 종료상태를 인지하고 kernel에게 알려줘야 한다는 것이다. 그 시스템 콜은 child process에게 할당된 자원을 kernel이 해제해주게 된다. 

위에 기술했던 상황 모두 zombie 상태는 발생하게 된다. 하나의 process는 종료와 process table에서 제거되는 시점 사이에 잠시 zombie 상태를 거처간다. 어떤 경우는(parent process가 잘못 구현되어 wait 시스템 콜을 호출하지 않고 종료한 경우), child process가 종료상태를 parent에 알려주지 못한 상태에서 종료를 하여 썼던 자원은 해제가 되었겠지만 시스템의 다음 rebooting 까지 process table을 차지 할 수 있다.(zombie 상태로 오래 남아있는 경우다) 이것은 ps나 top 명령어로 확인 될 수 있다. process table에 남아 있는 zombie 상태는 kernel의 아주 작은 영역을 차지하고 있어 큰 문제가 되질 않는다. 

조금씩이나마 정리를 해보려고 한다. 

우선은 "Professional Linux Kernel Architecture" 책을 번역하며 Comment 정도만 작성하는 식으로 진행을 해 볼까 한다. 

물론 영문을 번역하며 오역이나 내용의 헛점이 있을 수 있음을 알려드립니다. 꾸벅.

Chapter 2, Process Management and Scheduling

요즘 나오는 Operating System은 한번에 여러 개의 Process들을 실행 할 수 있다.(이것은 User 입장에서 그렇게 수행되는 것처럼 느껴지는 것이다.)  만약 하나의 시스템에 하나의 CPU를 가지고 있다면, 주어진 시간에 하나의 Process만을 실행 시킬수 있다. Multi-Processor 시스템에서는 물리적인 CPU 개수 만큼 Process들을 병렬적으로 수행 시킬 수 있다. 

Kernel과 Processor는 매우 빠른 간격으로 서로 다른 Application간에 번갈아가며 실행함으로써 시스템이 Multi-tasking(병렬적으로 여러 operation을 수행하는 능력)을 하는 것처럼 만들어 준다. 번갈아 실행하는 간격이 매우 짧기 때문에 User들은 Process가 일정 시간동안 활동하지 않는 상태임을 알지 못하고, 컴퓨터가 실제로 한번에 여러 일을 하는 듯한 느낌을 받게 된다. 

Kernel에서 해결해야할 중요한 시스템 관리 이슈들이 이 있고 이중 중요한 것은,

□ Application들은 일부러 그렇게 만들어 지지 않는 이상, 다른 Application을 간섭할 수 없다. 예를 들어, error를 가지고 실행하는 application A는 Application B에게 영향을 줄 수 없다. Linux는 multi-user 시스템이기 때문에, 프로그램들이 다른 프로그램의 메모리 영역을 읽거나 쓰게 할 수 없도록 해야 한다. 만약 그렇지 않으면, 다른 user들의 개인 data를 쉽게 접근할 수 있는 문제점이 있다. 

□ CPU 사용시간은 다양한 Application 사이에 최대한 공평하게 주어져야 하며, 이것은 어떤 프로램이 다른 것들 보다 더 중요한지 결정하는 것 중요한 포인트가 된다. 

 이 장에서는 kernel이 CPU 사용 시간을 어떻게 공유하고 process간 switch하는 방법을 설명한다.

이 두가지 작업은 각각 독립적으로 수행되는 두개의 부분으로 나누어져있다. 

□ kernel은 반드시 각 process들에게 얼마나 수행해야 하는지 그리고 언제 다른 process와 교체되어야 하는지 결정해야한다. 이것은 실제로 어떤 process가 다음에 수행되어야하는지에 대한 논점과는 다른 것이다. (다음 수행되어야 하는 것이 미리 결정되어 있진 않다) 이런 종류의 결정은 platform에 의존적이지 않다.(알고리즘에 결정된다는 뜻?)

이 단순화된 모델(그림 2-1)은 몇 가지 중요한 문제를 다루지 않은 것이다. 예를 들어, process들이 아직 실행 할 것이 없어 준비되지 않은 경우이다. 이 경우에 CPU 시간을 할당 했다고 해서 실행을 하면 아무 것도 하지 않고 시간만 까먹는 것이므로 효율적으로 사용하기 위해서는 이런 process들은 실행을 안 시키는 것이 좋다. <그림 2-1>에서는 모든 process가 실행 가능한 상태에서 CPU 자원을 대기중이라는 가정하에 시행한 것임을 알려드린다. 또 한가지는 Linux는 두가지의 scheduling class를 제공한다.(Completely Fair Scheduling, Real-time Scheduling) 

kernel 개발자들 사이에서는 scheduling의 일부인 다음 수행될 process를 선택하는 알고리즘에 대한 논의가 활발하다.(그만큼 중요하고 개발의 여지가 많아서 인듯). scheduler의 질적 향상에 대한 측정은 거의 불가능 하다. scheduler는 Linux System이 직면한 다른 많은 workload에 의해 생긴 요구사항을 해결 하기 위한 도전적인 과제일 것이다. 자동화된 조작을 위한 작은 embedded system에서는 대형 컴퓨터에서 요구되는 사항과는 많이 다를 것이다. 사실, scheduler code는 최근 두 가지 형태로 알아볼 수 있다. 

1. 2.5 version에서 개발 되는 동안, 기존의 scheduler를 대체하는 O(1) 대체하는 소위 O(1) scheduler 가 있다. 이 scheduler의 한가지 특별한 점은 System에 수행되고 있는 process 개수에 관계없이 상수시간에 다음 실행할 process를 선택할 수 있다. 이런 설계는 기존 scheduling 구조를 완벽히 바꾼 계기라고 할 수 있다.

2. Completely fair scheduling 은 kernel 2.6.23 버전까지 개발 진행되어 추가되었다. 이 새로운 코드는 기존의 원칙을 버리고 완벽한 시도가 되는 출발점이 된다.예를 들면, 이전 scheduler에서 요구된 것을 바탕으로 대화식의(vim program 등의 편집기) process는 응답시간을 빠르게 해주는 것이 된다. 이 scheduler의 중요한 포인트는 이상적인 fair scheduling 을 가능한 가깝게 구현하도록 노력했다는 것이다. 게다가 그것은 각각의 task들을 scheduling 할 뿐만 아니라, 더 일반적인 scheduling 단위에서도 잘 동작한다. 이는 다른 사용자들의 모든 process 간의 시간 분배와 각 사용자들이 사용하고 있는 process들 사이에서도 가능한 시간을 분배할 수 있도록 고려되어 있다. 

2-1 을 마무리 합니다. 틈틈히 읽어보고 수정사항이 있다면 변경하도록 하겠습니다.