2.3.1 Process Types
 일반적인 Unix process는 binary code로 구성되고 chronological(연대순의, 번역하기가 어려운 단어라..) thread (컴퓨터는 한시점에 코드를 통해 한시점에 하나의 경로로 실행하는 의미의 말) 그리고 application에게 할당된 자원의 셋(메모리, 파일 등)을 가진 것이다. 새로운 process들은 fork exec 시스템 콜의 조합으로 생성된다. 

fork 는 현재 process를 복제하여 생성한다. 이 복사본은 child process라 불린다. 원래의 process의 모든 자원은 적절한 방법으로 복사되어 시스템 콜 이후에 최초 process의 독립적인 두개의 객체가 있게 된다. 이 객체들은 어떤 방법으로 연결되어 있진 않지만, 열린 파일, 같은 작업 디렉토리, 메모리의 같은 데이터(data의 복사본을 각각 가지고 있게됨) 등을 가지고 있다. 

exec 는 수행중인 process를 실행 가능한 binary 파일로 부터 다른 application 을 로드한다. 결국 새로운 program을 로드한다는 말이다. exec 은 새로운 process를 생성하지 못하기 때문에 fork 시스템 콜로 process를 새로 복사한 후, 시스템에 추가적인 새로운 application을 생성하기 위해 exec을 호출한다. 

Linux는 위 두개의 system call 이외에 추가적인 clone 시스템 콜을 제공한다. 원칙적으로는 clone 은 fork와 같은 방식으로 구동된다. 하지만 새로 생성된 process는 그것의 parent process와 완전히 독립적이지 않으며 parent와 몇몇 자원은 공유한다. 이 시스템 콜은 어떤 자원은 복사되고, 어떤 자원은 공유하게 하는지에 정의가 가능하다.-예를 들면, memory에 있는 data, 열린 파일들, signal handler등이 있다. 

clone은 tread를 구현할 때 사용된다. 그렇지만 thread를 수행하기 위해서는 이것만 가지고는 할 수 없다. user level에서 완전히 실행되기 위해서는 라이브러리들이 필요하다. 예를 들면, Linuxthreads Next Generation Posix Threads와 같은 라이브러리 들이다. 
1. Linux Cross Reference site 이용
 
사이트에 접속하면 빨간 박스를 클릭하여 최신 버전의 소스 최상위로 진입할 수 있다. 

선택후, 

빨간 동그라미 부분을 클릭하면 버전별 소스 트리를 선택할 수 있다. 일단 2.6.37.1 최신버전을 선택
그리고 바로 옆 search 박스에서 테스트로 "task_struct" 를 입력하고 search 버튼을 누른다. 

찾은 "task_struct" 두가지로 분류되어 있다. "Extern or forward variable declaration"(위의 그림) 과 "Structure"(아래 그림)
include/linux/sched.h 를 클릭하여 소스를 보도록 하자.

위와 같이 소스를 볼수가 있다. include file이나 각종 변수 및 선언된 내용(파란색 글)은 모두 클릭하여 연결된 소스를 웹에서 볼수가 있다. 

2. Program의 이용
분석툴로는 Linux 에서는 vim + ctags + cscope 방법과 Window에서 사용하는 SourceInsight 가 있다.(물론 유료버전임.. 30일 무료버전을 다운받아 사용해보는 것을 추천한다.) 

이미 내용을 잘 써놓은 블로그가 검색하면 쫙 나오기에.. 검색해보고 찾은 것중 참고할 만한 글을 링크합니다. 

a. http://sosal.tistory.com/11 커널 분석기(vim+ctags+cscope) 정리한 블로그 입니다. 
b. sourceInsight 사용법 : http://wizlog.net/60 (시작하기에 좋은 참고 블로그입니다.)
  - 한글 주석 입력방법 : http://jany.tistory.com/47

3. Get Linux Kernel Source
Web Browser : www.kernel.org
빨간 박스는 최신버전을 바로 다운로드 할 수 있는 링크임.

국내 미러 사이트의 주소는 
여기서 v숫자(ex. v2.6) 를 클릭하여 들어가면 관련 버전의 소스를 다운받을 수 있다. 

Console에서는 
wget을 이용한다.(없으면 설치해야함. ubuntu는 "sudo apt-get install wget" 하면됨.

$ wget -c http://<mirror site>/pub/linux/kernel/v2.6/linux-<version>.tar.bz2

version은 linux-2.6.23.7.tar.gz 이런 식으로 입력하면 됩니다. 
Chapter 2, Process Management and Scheduling


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

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

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

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


task_struct 의 링크는 
이다. 링크에서 보는 바와 같이 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를 연결하기 위한 포인터 등으로 구성되어 있다. 중요한 변수들 몇몇을 자세히 설명해본다. 



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 에 정의되어 있다. 

이 정의(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 우선 순위의 최대치.



+ Recent posts