Daeseok's Blog

---

2.3 Process Representation

Process와 program에 관련된 Linux Kernel의 모든 알고리즘은 include/sched.h 에 정의되어 있는 task_struct 라는 data 자료구조 내부에 있다. 이 자료구조는 시스템의 중심적 역할은 하는 것들 중에 하나이다. scheduler의 구현부를 다루기 전에, 이 기본적인 자료구조를 알아야 한다. 

task 구조체는 많은 process를 연결하는 요소들을 포함하고 있다. 구조체 내부의 요소들을 잘 알지 못하고는 차후에 나오는 내용을 이해시키기는 어려울 것이다. 

task 구조체는 다음과 같이 정의되어 있다.

task_struct 소스 내용을 모두 넣는 것이 쓰는 사람도 읽는 사람도 불편할 것이니 다른 방법을 사용한다. 물론, 필요한 부분은 넣어야겠지..

소스 보는 방법 <-- 클릭

task_struct 의 링크는 

http://lxr.linux.no/#linux+v2.6.37.1/include/linux/sched.h#L1182

이다. 링크에서 보는 바와 같이 2.6.37.1 version 의 소스이다. 책의 내용과 조금 차이가 있을 수 있다. 

소스를 보면 알겠지만, 이 구조체의 많은 정보를 다 소화하기란 어려운 일일 것이다. 그렇지만, 이 구조체를 process의 특정 한 상태를 표현하는 등의 부분 부분으로 나누어 본다면 조금 수월할 것이다. 

□ Process 상태 및 실행 정보 : 지연된 signal, 사용된 binary 포멧(또한 다른 시스템의 binary 포멧을 위한 emulation 정보 등), process ID(pid), 자신의 부모 process 및 관련 process의 연결 포인터, 우선순위 값, 마지막으로 program을 실행한 시간 정보(CPU time)

□ 할당된 가상 메모리(virtual memory) 정보

□ process 자격 : user ID, group ID, process가 특정 명령을 수행할 권한 정보 등. System call 을 통해 process 정보등을 확인 하고 변경할 수 있다. 

□ 사용된 file : program code를 포함하는 binary file 뿐만 아니라 process가 다루는 모든 file의 filesystem 정보는 저장해야한다. 

□ Thread 정보, process의 CPU 관련 runtime data 를 기록하게 됨.(그 외 남은 구조체의 field 는 사용된 하드웨어와 의존적이지 않다 - stack 정보같은 것인듯.)

□ 다른 process와 함께 같이 작업할 때, Process간 통신(Interprocess Communication)에 대한 정보

□ process가 signal에 응답하기 위해 등록한 signal handler

task 구조체는 간단하게 값들이 구성되어 있지 않다. 각종 data를 연결하기 위한 포인터 등으로 구성되어 있다. 중요한 변수들 몇몇을 자세히 설명해본다. 

//<Linux TOP>/include/linux/sched.h struct task_struct { volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */ void *stack; atomic_t usage; ... /* task state */ int exit_state; //EXIT_ZOMBIE, EXIT_DEAD int exit_code, exit_signal; int pdeath_signal; /* The signal sent when the parent dies */

state 는 process의 현재 상태를 기술한다. (volatile long으로 선언됨) 

□ TASK_RUNNING : Task가 수행 가능한 상태이다. 이것은 실제 CPU에 할당되어 수행중이라는 것은 아니다. scheduler에 의해 선택될 때까지 이 task는 기다릴 수 있다. 이 상태는 process가 실행 가능한 상태이며 외부 event를 기다리고 있지 않다는 것이다. 

□ TASK_INTERRUPTIBLE : 어떤 event를 기다리는 잠자고 있는(sleeping) process를 위한 설정이다. 기다리던 event가 발생하게 되면, 이 상태는 TASK_RUNNING 으로 변경되면 scheduler에 의해 선택되면 바로 실행이 가능하게 된다. 

□ TASK_UNINTERRUPTIBLE : kernel의 명령으로 잠들어 있는 process를 disable 시킨 상태. kernel이 직접 해제하지 않는다면, 외부 signal에 의해 깨어나 수행할 수 없다.

□ TASK_STOP : process가 특정목적을 위해 멈춰있는 경우이다.(예를 들면, debugger의 break point에서 멈추게 함.)

□ TASK_TRACED : 이 process의 상태는 ptrace 매커니즘을 이용해 process가 특정 시점에서 trace되고 있는 상태로 일반적인 STOP 된 task와 구별하기 위함이다. 

이 다음에 나오는 상수는 종료되는 process의 상태를 나타내준다. 이것은 exit_state 항목에 저장된다.

□ EXIT_ZOMBIE : 2.2 에서 설명된 zombie 상태를 나타낸다.

□ EXIT_DEAD : 시스템에서 완전히 제거되기 전에 parent process에서 알맞은 wait system call을 호출한 뒤의 process 상태. 이 상태는 하나의 task 안에서 여러 개의 thread가 수행될 때 중요하게 사용되는 상태이다. 

Linux는 process의 시스템 resource 사용 제한을 위해 resource limit (rlimit) 메커니즘을 제공한다. 이 메커니즘은 task_struct 안에 signal 구조체 포인터가 있다. process signal 관리를 위한 구조체 내부에 rlim이라는 배열이 존재한다. ( 아마 책에는 task_struct 내부에 rlim 배열이 있다고 하는데, 소스를 보니 task_struct --> singal_struct *signal-->struct rlimit rlim[] 로 되어 있다.)

rlimit 구조체는 include/linux/resource.h 에 정의되어 있다.  //<Linux TOP>/include/linux/resource.h struct rlimit { unsigned long rlim_cur; unsigned long rlim_max; };

이 정의(definition)은 다른 많은 resource를 수용하기 위해 매우 일반적으로(?) 유지된다. 

□ rlim_cur : process의 현재 자원 제한. 이것은 soft limit 로 참조된다.

□ rlim_max : process가 허가된 최대 자원의 제한. 이것은 hard limit 으로써 참조된다.

setrlimit system call은 현재 자원제한을 증가시키거나 감소시키는데 사용한다. 그렇지만 이 값은 rlimt_max 값을 초과할 수 없다. getrlimit system call로 현재 limit 값을 확인 할 수 있다. 

이 제한적인 자원은 rlim 배열의 index로 자신의 위치를 확인 할 수 있는데, 이것은 kernel에서 상수값으로 미리 정의를 해두어 연결된 자원과 배열의 위치를 연결했다. Table 2-1을 보면 정의된 상수와 그것의 의미를 기술했다. System programming 책을 보면 자원 제한관련 예제 및 더 상세한 내용을 볼 수 있다. 또한, setrlimit(2) man page를 봐도 조금 더 자세한 내용을 볼 수 있다. 

Linux 는 특정 유닉스 시스템과 binary 호완성을 제공하기 위한 노력을 해왔기 때문에 아키텍쳐 마다 상수의 값들은 서로 다를 수 있다.

limit은 kernel의 매우 다른 부분과 연관되어 있기 때문에, kernel은 반드시 대응되는 하위 시스템의 limit 값을 확인해야 한다. 

만약 resource type이 limits(거의 모든 자원의 기본 설정임) 설정 없이 사용되었다면, RLIM_INFINITY 의 값으로 rlim_max 가 설정된 것이다. 예외적으로 사용된 경우를 보자, 

□ 열린 파일들의 수(RLIMIT_NOFILE, 기본적으로 1024로 제한한다.)

□ 사용자가 가질 수 있는 process의 개수(RLIMIT_NRPROC)은 "max_thread / 2"로 정의한다. 여기서 max_thread는 global 변수이며, 가용한 RAM의 1/8이 thread 정보를 관리하는데만 사용하고 20개의 thread가 최소의 메모리만을 사용하도록 thread의 생성 개수를 정의한다. (이문장은 번역에 어려움을 겪어 최대한으로 부드럽게 하려고 노력하였음.)

init task를 위한 부팅 때 자원 자한은 include/asm-generic-resouce.h 안에 INIT_RLIMTS 로 정의되어 있다. 

각 process의 proc filesystem을 통해 rlimit 값을 확인 할 수 있다. 

현재 나의 system 정보는 : VMware Server 2.0.1에 Ubuntu 10.10을 설치했다. 10.10의 kernel version은 2.6.35-22 다. 

rlimit 값을 확인 하기 위해, 

proc/self/limits 파일을 읽었다. proc file system의 self 라는 file은 symbolic link 이며 현재 수행중인 process를 가르키고 있다. 

Table 2-1: Process 관련 자원 제한. 

상수	의미
RLIMIT_CPU	최대 할당 할 수 있는 CPU 시간
RLIMIT_FSIZE	사용할 수 있는 file 최대 크기
RLIMIT_DATA	data segment의 최대 크기
RLIMIT_STACK	(user mode) stack의 최대 크기
RLIMIT_CORE	core dump file의 최대 크기
RLIMIT_RSS	Resident Size Set 의 최대 크기; 다른 말로는 process가 사용할 수 있는  최대 page frame의 개수이다. 현재 사용되지 않은 것도 포함함.
RLMIT_NPROC	실제 UID 에 연관된 사용자가 하나의 process를 가지고 생성할 수 있는 process의 최대 개수(fork의 제한 인듯) - 조금 더 알아봐야 할듯.
RLIMIT_NOFILE	하나의 process가 제어할 수 있는 파일의 개수(open files)
RLIMIT_MEMLOCK	swap 되지 않도록 할 수 있는 page 의 개수
RLIMIT_AS	하나의 process가 차지할 수 있는 가상 주소 공간의 최대 사이즈
RLIMIT_LOCKS	file lock의 최대 개수
RLIMIT_SIGPENDING	지연된 signal의 최대 개수
RLIMIT_MSGQUEUE	message queue의 최대 개수
RLIMIT_NICE	non-real time process들을 위한 최대 nice 레벨
RLIMIT_RTPRIO	real time 우선 순위의 최대치.

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

우선은 "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 을 마무리 합니다. 틈틈히 읽어보고 수정사항이 있다면 변경하도록 하겠습니다.