IT/모바일
저자: 서민우
출처: Embedded World
본 기사는 리눅스 커널 2.6이 hardware interrupt와 system call을 중심으로 어떻게 설계되었고, 구현 되었는지 살펴본다. 이 과정에서 리눅스 커널 2.6에 새로이 추가된 커널 preemption 기능을 자세히 살펴보기로 한다. 또한 커널의 동기화 문제와 이에 대한 해결책 등을 커널 source 내에서 찾아보기로 하고, 후에 device driver등을 작성할 때 이러한 해결책을 어떻게 적용할 수 있을지도 생각해 본다. 다음으로 리눅스 커널 2.6에 추가된 O(1) scheduler를 소스 수준에서 자세히 살펴 보기로 한다. 또한 task queue의 변형된 형태인 work queue의 사용법을 알아보기로 한다. 마지막으로 리눅스 커널 2.6에서는 어떻게 device driver를 작성해야 할지 구체적인 예를 보기로 한다.
이번 기사에서는 리눅스 커널을 소스 수준에서 구체적으로 들여다 보기 전에 일반적인 커널의 동작을 살펴보고, 이를 바탕으로 리눅스 커널의 전체적인 동작을 살펴보기로 한다.
1. 일반적인 커널의 동작
여기서는 process와 device 사이에서 커널이 수행해야 할 구체적인 역할을 몇 가지 살펴보고, 이를 기본으로 해서 일반적인 커널의 동작을 이해해 보기로 한다.
system call에 의한 커널의 구체적인 동작 1
일반적으로 process는 system call을 통해 커널에게 device로부터 data를 읽기를 요청한다. 그러면 커널은 device로부터 data를 읽기를 요청하고 현재 수행중인 process를 잠시 멈추기 위해 wait queue에 넣는다. 왜냐하면 device로부터 data가 도착해야 그 process를 다시 진행할 수 있기 때문이다(wait, sleep, block과 같은 용어는 이러한 상황에서 쓰인다). 그리고 새로운 process를 적절한 기준에 의해 선택해 수행하기 시작한다. 새로운 process를 선택하고 그 process로 전환하는 과정을 process scheduling이라고 한다. 그 이후에 몇 번의 process scheduling이 더 있을 수 있다.
이 과정을 processor의 관점에서 다시 보자.
processor가 process의 사용자 영역(응용프로그램 영역)을 수행하는 중에 system call 명령을 만나면 커널 영역으로 뛰어 들어간다. 커널 영역에는 device로부터 data를 읽기를 요청하고 현재 수행중인 process를 잠시 멈추기 위해 wait queue에 넣고 새로운 process를 선택해 수행하는 일련의 명령들이 있다(이러한 일련의 명령들을 process 또는 커널이 수행할 작업이라고 하자). 이러한 명령들에 따라 결국 processor는 새로운 process를 선택해 수행하기 시작한다. 그 이후에 몇 번의 process scheduling이 더 있을 수 있으며, processor는 임의의 시간에 임의의 process를 수행하고 있다.
hardware interrupt에 의한 커널의 구체적인 동작
processor가 임의의 process를 수행하는 동안에 device에는 data가 도착한다. device는 data의 도착을 물리적인 신호를 통해서 processor에게 알린다(이를 우리는 hardware interrupt라고 한다). 그러면 processor는 이 신호를 감지하고 커널 영역으로 뛰어 들어간다. 커널 영역에는 device에 도착한 data를 메모리로 읽어 오고, 그 data를 사용할 process에 맞게 적절하게 형태를 바꾸어, data를 기다리는 process에게 전달하고, 그 process를 wait queue에서 꺼내 ready queue로 집어넣은 후, ready queue로 들어간 process의 우선순위가 현재 수행 중이던 process의 우선순위보다 클 경우 process scheduling을 요청한 후 process scheduling을 수행하는 일련의 명령들이 있다. 이러한 명령들에 따라 결국 processor는 device로부터 data를 읽기를 요청한 process를 다시 선택해 수행하기 시작한다. processor는 다시 시작한 process의 커널 영역에서 사용자 영역으로 빠져 나가 사용자 영역을 계속해서 수행한다.
[그림 1]을 보면서 좀 더 구체적으로 이해해 보자. process P1은 사용자 영역의 A 부분에서 system call을 통해 커널 영역으로 들어간다. 커널 영역의 B 부분에서 device로부터 data를 읽기를 요청한 후 현재 수행중인 process를 wait queue에 넣는다. 그리고 C 부분에서 process scheduling을 수행한다. 이 부분을 좀 더 자세히 들여다보면 C 부분에서 시작한 process scheduling은 D 부분에서 끝나지 않고 process P2의 E 부분에서 끝난다. 즉, c 지점으로 들어가서 e 지점으로 나온다.
process scheduling
여기서 process scheduling의 동작을 좀 더 구체적으로 살펴보자. process scheduling은 크게 두 동작으로 나뉜다. 처음 동작은 새로 수행할 process를 선택하는 부분이다. 두번째 동작은 현재 수행하고 있는 process의 상태를 저장한 다음 새로 수행할 process의 상태를 복구하는 것이다. 이 동작을 우리는 문맥 전환이라고 한다. processor는 내부에 여러 개의 register를 가지고 있으며, 이 register를 이용해 process를 수행해 나간다. register는 memory와 같이 data를 저장하는 기능을 하지만, 접근 속도가 memory보다 빠르다. 따라서 비용상 그 개수가 많지는 않다. register는 processor architecture에 따라 R0, R1, ... 또는 EAX, EBX, ... 등의 이름을 가지며, 32 bit RISC processor의 경우 일반적으로 32 bit의 크기를 갖는다. processor는 register와 memory 또는 I/O device내의 register간에
data를 옮겨가면서 procss를 수행해 나간다. 따라서 process를 수행해 나감에 따라 register의 내용은 계속 바뀌게 된다. 문맥 전환 부분을 좀 더 자세히 들여다 보면 processor가 현재 process를 수행해 나가다 어느 순간에 register의 내용을 그대로 메모리에 저장한다. 새로 수행할 process의 경우도 현재 process처럼 이전에 저장한 register의 내용이 메모리에 있으며, 따라서 그 메모리에 저장한 register의 내용을 다시 processor의 register로 복구 시킨다. 그리고 새로운 process를 계속 수행해 나간다.
문맥 전환(context switching)
문맥 전환 부분을 좀 더 구체적으로 이해하기 위해 process scheduling의 동작을 다음과 같이 가정해 보자. 처음 동작에서 새로 수행할 process를 뽑았는데 그 process가 현재 수행하고 있던 process였다. 그러면 두 번째 동작은 다음과 같이 될 것이다. processor가 현재 process의 register의 내용을 메모리에 저장한다. 그리고 방금 전에 메모리에 저장한 register의 내용을 다시 processor의 register로 복구 시킨다. 그리고 현재 process를 계속 수행한다. 이럴 경우 [그림 1]에서 C 부분에서 시작한 process scheduling은 D 부분에서 끝나며, 논리적으로 process scheduling을 수행하지 않은 것과 같다. process scheduling의 본래 목적은 process간의 전환이며 따라서 현재 process와 새로 수행할 process가 있어야 그 본래 기능을 수행할 수 있다. 여기서는 문맥 전환의 동작을 이해하기 위하여 이와 같은 가정을 한 것이다.
[그림 1] system call과 hardware interrupt에 의한 커널의 구체적인 동작
그러면 process scheduling의 본래 기능으로 다시 돌아가 문맥 전환을 생각해 보자.
[그림 1]에서 현재 process를 P1, 새로 수행할 process를 P2라 하자. 그러면 process P1의 C 부분에서 시작한 process scheduling이 논리적으로 D 부분에서 끝나야 하는 것처럼(여기서는 실제로 J 부분에서 끝난다) 이전에 process P2의 F 부분에서 시작한 process scheduling은 논리적으로 E 부분에서 끝나는 것이다. 그러나 시간상으로는 process P1의 C 부분에서 시작한 process scheduling은 process P2의 E 부분에서 끝난다. 즉, c 지점으로 들어가서 e 지점으로 나온다.
이후에 process P2에서 process P3로(f에서 g로), process P3에서 process P4로, 몇 번의 process scheduling이 더 있을 수 있으며(h에서 … i로), 어느 순간 임의의 process Pn이 수행 중일 수 있다. [그림 1]에서 process Pn을 수행하는 중에 G 부분에서, process P1의 B 부분에서 data를 읽기를 요청한 device로부터, hardware interrupt가 들어올 수 있다. 그러면 process Pn은 G 부분에서 커널 영역으로 들어간다. 커널은 H 부분에서 device에 도착한 data를 메모리로 읽어 오고, 그 data를 사용할 process P1에 맞게 적절히 형태를 바꾸어 process P1에게 전달하고, process P1을 wait queue에서 꺼내 ready queue로 넣은 후, 새로이 ready queue로 들어간 process P1의 우선순위가 현재 수행 중인 process Pn의 우선순위보다 클 경우 process scheduling을 요청한다. 그러면 I 부분에서 process scheduling을 수행한다. process Pn의 I 부분에서 시작한 process scheduling은 process P1의 J 부분에서 끝난다. 덧붙이자면, process P1의 C 부분과 J 부분은 시간적으로는 연속이지 않지만 논리적으로는 연속이다.
hardware interrupt에 의한 커널의 일반적인 동작
이제 hardware interrupt에 의해 시작한 커널의 일반적인 동작을 정리해 보자.
[그림 1]에서 process Pn을 수행하는 중에 들어온 hardware interrupt에 의해 시작한 커널의 동작은 다음과 같다.
1. device에 도착한 data를 메모리로 읽어 온다.
2. data를 사용할 process에 맞게 적절하게 형태를 바꾼다.
3. data를 기다리는 process에게 전달하고 process scheduling 요청
4. process scheduling을 수행
여기서 커널의 동작은 크게 세 부분으로 나눌 수 있으며, 그 처음 부분은 다음과 같다.
1. device에 도착한 data를 메모리로 읽어 온다.
이 부분은 hardware interrupt를 처리하는 부분으로써 신속하게 device로부터 data를 읽어냄으로써 빠른 시간 내에 device가 외부로부터 다시 data를 받을 수 있게 한다. 일반적으로 이 부분에서는 또 다른 device로부터 오는 hardware interrupt를 허용하지 않음으로써 신속하게 device로부터 data를 읽어낸다. 리눅스 커널에서는 이 부분을 top half라고 하기도 하고 interrupt handler라고도 한다.
다음으로 두 번째 부분은 다음과 같다.
2. data를 사용할 process에 맞게 적절하게 형태를 바꾼다.
3. data를 기다리는 process에게 전달하고 process scheduling 요청
이 부분은 기본적으로 hardware interrupt를 허용함으로써 응답성을 좋게 한다. 이 과정은 device에서 읽어온 data를 적당하게 처리해 그 data를 기다리는 process에게 전달하고 필요시 process scheduling을 요청한다. 리눅스 커널에서는 이 부분을 bottom half라고도 하고, deferred work라고도 하고, softirq라고도 한다. 덧붙이자면 3번 동작을 리눅스 커널에서는 wake_up이라고 한다.
마지막으로 세 번째 부분은 다음과 같다.
4. process scheduling을 수행
이 부분은 두 번째 부분에서 process scheduling을 요청할 경우 수행한다. 리눅스 커널에서는 이 부분을 schedule이라고 한다.
이상에서 hardware interrupt에 의한 커널의 동작은 [그림 2]와 같다.
[그림 2] hardware interrupt에 의한 커널의 일반적인 동작
[그림 1]에서 한 가지 주의할 점은 process Pn의 사용자 영역을 수행하는 중에 들어온 hardware interrupt에 의해 시작한 커널의 동작은 process Pn과 논리적으로 관련이 없다. 따라서 앞에서 설명한 처음 동작과 두 번째 동작을(top half와 bottom half를) 수행하는 중에 현재 process Pn은 논리적으로 멈출 일이 없으며, 따라서 wait queue에 들어갈 일은 없다.
top_half, bottom_half와 system call function간의 통신
마지막으로 한 가지만 더 짚고 넘어가면, [그림 1]에서 process P1의 system call에 의해 시작한 커널과 process Pn의 사용자 영역 수행 중에 발생한 hardware interrupt에 의해 시작한 커널은 각각 논리적으로 독립된 흐름을 가지며 B 부분과 H 부분에서 통신을 한다. 즉, H 부분에서 data를 공급하며, B 부분에서 data를 소비한다. [그림 3]은 [그림 1]의 system call에 의한 커널과 hardware interrupt에 의한 커널간에 data를 주고 받는 상황을 논리적으로 표현한 것이다.
[그림 3] top_half, bottom_half와 system call function간의 통신
system call에 의한 커널의 구체적인 동작 2
[그림 4]를 보면서 다음의 내용을 이해해 보자.
P1, Pn이라 하는 두 process가 있다고 가정하자. process P1는 system call([그림 4]의 A 부분)을 통해 커널에게 process Pn으로부터 data를 받기를 요청할 수 있다. 그러면 커널은 Pn으로부터 P1에게 도착한 data가 있는지 검사한다([그림 4]의 B 부분). P1에게 도착한 data가 없을 경우 커널은 현재 수행중인 process P1을 잠시 멈추기 위해 wait queue에 넣는다([그림 4]의 B 부분). 왜냐하면 process Pn으로부터 data가 도착해야 process P1을 다시 진행할 수 있기 때문이다. 그리고 새로운 process를 선택해([그림 4]의 C 부분) 수행하기 시작한다. 이 동작을 우리는 앞에서 process scheduling이라 했다. 그 이후에 몇 번의 process schduling이 더 있을 수 있다. ([그림 4]에서 process P2에서 process P3로)
[그림 4] system call에 의한 커널의 구체적인 동작
system call에 의한 커널의 구체적인 동작 3
어느 순간 process Pn은 process scheduling에 의해 다시 시작하며([그림 4]의 D 부분) 사용자 영역을 수행하다 system call을 통해([그림 4]의 E 부분) 커널에게 process P1에게 data를 보내기를 요청할 것이다. 그러면 커널은 process Pn으로부터 process P1으로 data를 전달하고([그림 4]의 F 부분), process P1을 wait queue에서 꺼내 ready queue로 넣은 후, ready queue로 새로이 들어간 process P1의 우선순위가 현재 수행 중이던 process Pn의 우선순위보다 클 경우 process scheduling을 요청한 후([그림 4]의 F 부분) process scheduling을 수행한다. process scheduling은 [그림 4]의 G 부분에서 시작해 H 부분에서 끝난다. 즉, process scheduling이 끝나면 process P1이 수행을 다시 시작한다.
system call에 의한 커널의 일반적인 동작
이제 system call에 의해 시작한 커널의 일반적인 동작을 정리해 보자. 먼저 system call은 software interrupt라고도 한다. 주의할 점은 software interrupt는 리눅스 커널내의 bottom half의 또 다른 이름인 softirq와는 관련이 없다.
[그림 1]에서 process P1을 수행하는 중에 들어온 system call에 의해 시작한 커널의 동작은 다음과 같다.
1. device로부터 data를 읽기를 요청한다.
2. 현재 수행중인 process를 wait queue에 넣는다
3. process scheduling을 수행
이 부분은 process의 요청에 의해 커널이 수행하는 영역이며, 상황에 따라 현재 process를 논리적으로 더 이상 진행시킬 수 없는 경우 현재 process를 wait queue에 넣고 process scheduling을 수행할 수 있다. 이 부분은 system call 함수의 일부분이다. 2, 3번 항목은 리눅스 커널의 sleep_on 또는 wait_event와 대응한다.
[그림 4]에서 process P1을 수행하는 중에 들어온 system call에 의해 시작한 커널의 동작은 다음과 같다.
1. process Pn으로부터 도착한 data가 있는지 검사한다.
2. 현재 수행중인 process를 wait queue에 넣는다.
3. process scheduling을 수행
이 부분도 process의 요청에 의해 커널이 수행하는 영역이며, 상황에 따라 현재 process를 논리적으로 더 이상 진행할 수 없는 경우 현재 process를 wait queue에 넣고 process scheduling을 수행한다. 이 부분도 system call 함수의 일부분이다. 여기서도 2, 3번 항목은 리눅스 커널의 sleep_on 또는 wait_event에 대응한다.
[그림 4]에서 process Pn을 수행하는 중에 들어온 system call에 의해 시작한 커널의 동작은 다음과 같다.
1. process P1에게 data를 전달하고 process scheduling 요청
2. process scheduling을 수행
여기서는 커널의 동작을 두 부분으로 나눌 수 있으며, 처음 부분은 다음과 같다.
1. process P1에게 data를 전달하고 process scheduling 요청
이 부분은 process의 요청에 의해 커널이 수행하는 영역이며, system call 함수의 일부분이다. 이 부분은 리눅스 커널의 wake_up에 대응한다.
두 번째 부분은 다음과 같다.
2. process scheduling을 수행
이 부분은 처음 부분에서 process scheduling을 요청할 경우 수행한다.
이상에서 system call에 의한 커널의 동작은 [그림 5]와 같다.
[그림 5] system call에 의한 커널의 일반적인 동작
[그림 5]에서 process scheduling(1)은, 현재 process P의 요청에 따라 커널이 process P와 관련된 작업을 수행하는 도중에 어떤 조건이 맞지 않아, 예를 들어 필요로 하는 data가 없어서, 더 이상 현재 process P의 작업을 진행할 수 없을 경우, 필요로 하는 조건이 맞을 때까지 현재 process P를 wait queue에 넣어 기다리게 하고 나서 수행하는 process scheduling이며, system call function내에서 수행을 한다. 한 가지 기억해야 할 점은 [그림 1]에서 C와 J 부분이 일반적으로 논리적으로는 연속이지만 시간상으로는 연속이 아니듯이 [그림 5]의 process scheduling(1)도 일반적으로 논리적으로는 연속이지만 시간상으로는 연속이 아니다. 후에 process P가 필요로 하는 조건이 맞으면, process P는 논리적인 흐름이 다른 커널(예를 들어, [그림 1]의 H 부분과 같은)에 의해 ready queue로 옮겨지며, 역시 논리적인 흐름이 다른 커널에서 시작한 process scheduling(예를 들어, [그림 1]의 I 부분과 같은)에 의해 [그림 5]의 process scheduling(1)로 나와 system call function의 나머지 부분을 수행한다. system call function 내에서는 이후에도 필요에 따라 process scheduling이 더 있을 수 있다. 이와는 달리 process scheduling(2)는 커널이 process P의 요청에 의해 system call function을 수행하는 도중에 wait queue에서 기다리던 임의의 process를 ready queue로 넣고, 그 ready queue에 넣은 process의 우선 순위가 현재 process P의 우선 순위보다 클 경우(예를 들어 [그림 4]의 F 부분과 같은)에 수행하는 process scheduling이다. 이 경우 현재 process P는 ready queue에 그대로 남아 있다.
system call function과 system call function간의 통신
마지막으로 한 가지만 더 짚고 넘어가면, [그림 4]에서 process P1의 system call에 의해 시작한 커널과 process Pn의 system call에 의해 시작한 커널은 각각 논리적으로 독립된 흐름을 가지며 B 부분과 F 부분에서 통신을 한다. 즉, F 부분에서 data를 공급하며, B 부분에서 data를 소비한다. [그림 6]은 [그림 4]의 system call에 의한 커널간에 data를 주고 받는 상황을 논리적으로 표현한 것이다.
[그림 6] system call function과 system call function간의 통신
process scheduling의 시작과 끝
우리는 [그림 2]와 [그림 5]에서 커널의 일반적인 동작과 process scheduling이 언제 수행되는지 보았다. 아래 [그림 7]에서 process scheduling이 시작되는 부분과 끝나는 부분이 어떻게 연결될 수 있는지 자세히 살펴 보자.
어떤 process의 a 부분에서 시작한 process scheduling은 임의의 다른 process의 b, d, f부분에서 끝날 수 있다. 또 어떤 process의 c 부분에서 시작한 process scheduling도 임의의 다른 process의 b, d, f 부분에서 끝날 수 있다. 마지막으로 어떤 process의 e 부분에서 시작한 process scheduling 역시 임의의 다른 process의 b, d, f 부분에서 끝날 수 있다.
[그림 7] process scheduling의 시작과 끝
지금까지 우리는 커널이 수행해야 할 일반적인 동작이 무엇인지 살펴 보았다. 즉, system call을 통해 시작한 커널의 동작, hardware interrupt에 의해 시작한 커널의 동작을 보았다. 이 과정에서 process와 device 사이에서 커널이 수행해야 할 역할이란 것이 우리가 모르는 그 어떤 것이 아니란 점도 느꼈을 것이다. 의외로 커널의 역할이 지극히 당연한 것들이라고 느꼈을 수도 있다. 또 hardware interrupt에 의해 시작한 커널과 system call에 의해 시작한 커널간의 통신, system call에 의해 시작한 커널과system call에 의해 시작한 커널간의 통신을 보았다. 이 과정에서 논리적으로 서로 독립적인 커널의 동작간에 통신이 어떻게 이루어지는지 구체적으로 알았을 것이다.
서민우 / minucy@hanmail.net
과학기술정보연구소 및 여러 대학교에서 임베디드 리눅스 실무과정을 강의하면서 리눅스 커널 초기버전을 분석하는 작업을 통해 초보자들도 OS 의 설계 및 구현에 대해 체계적으로 접근할 수 있는 방법에 대한 자료를 제작하는 데에 힘을 쏟고 있다. 50개 정도의 명령어, pipeline 등을 포함한 32 bit RISC CPU 를 설계 및 구현한 경험이 있고 uCOS/II 정도 수준의 OS 설계 및 구현에 대한 체계적인 접근 방법에 대한 자료까지 완성한 상태이며 지속적인 작업을 통해 커널과 OS에 관한 유용한 정보를 널리 공유하고자 노력하고 있다.
출처: Embedded World
본 기사는 리눅스 커널 2.6이 hardware interrupt와 system call을 중심으로 어떻게 설계되었고, 구현 되었는지 살펴본다. 이 과정에서 리눅스 커널 2.6에 새로이 추가된 커널 preemption 기능을 자세히 살펴보기로 한다. 또한 커널의 동기화 문제와 이에 대한 해결책 등을 커널 source 내에서 찾아보기로 하고, 후에 device driver등을 작성할 때 이러한 해결책을 어떻게 적용할 수 있을지도 생각해 본다. 다음으로 리눅스 커널 2.6에 추가된 O(1) scheduler를 소스 수준에서 자세히 살펴 보기로 한다. 또한 task queue의 변형된 형태인 work queue의 사용법을 알아보기로 한다. 마지막으로 리눅스 커널 2.6에서는 어떻게 device driver를 작성해야 할지 구체적인 예를 보기로 한다.
이번 기사에서는 리눅스 커널을 소스 수준에서 구체적으로 들여다 보기 전에 일반적인 커널의 동작을 살펴보고, 이를 바탕으로 리눅스 커널의 전체적인 동작을 살펴보기로 한다.
1. 일반적인 커널의 동작
여기서는 process와 device 사이에서 커널이 수행해야 할 구체적인 역할을 몇 가지 살펴보고, 이를 기본으로 해서 일반적인 커널의 동작을 이해해 보기로 한다.
system call에 의한 커널의 구체적인 동작 1
일반적으로 process는 system call을 통해 커널에게 device로부터 data를 읽기를 요청한다. 그러면 커널은 device로부터 data를 읽기를 요청하고 현재 수행중인 process를 잠시 멈추기 위해 wait queue에 넣는다. 왜냐하면 device로부터 data가 도착해야 그 process를 다시 진행할 수 있기 때문이다(wait, sleep, block과 같은 용어는 이러한 상황에서 쓰인다). 그리고 새로운 process를 적절한 기준에 의해 선택해 수행하기 시작한다. 새로운 process를 선택하고 그 process로 전환하는 과정을 process scheduling이라고 한다. 그 이후에 몇 번의 process scheduling이 더 있을 수 있다.
이 과정을 processor의 관점에서 다시 보자.
processor가 process의 사용자 영역(응용프로그램 영역)을 수행하는 중에 system call 명령을 만나면 커널 영역으로 뛰어 들어간다. 커널 영역에는 device로부터 data를 읽기를 요청하고 현재 수행중인 process를 잠시 멈추기 위해 wait queue에 넣고 새로운 process를 선택해 수행하는 일련의 명령들이 있다(이러한 일련의 명령들을 process 또는 커널이 수행할 작업이라고 하자). 이러한 명령들에 따라 결국 processor는 새로운 process를 선택해 수행하기 시작한다. 그 이후에 몇 번의 process scheduling이 더 있을 수 있으며, processor는 임의의 시간에 임의의 process를 수행하고 있다.
hardware interrupt에 의한 커널의 구체적인 동작
processor가 임의의 process를 수행하는 동안에 device에는 data가 도착한다. device는 data의 도착을 물리적인 신호를 통해서 processor에게 알린다(이를 우리는 hardware interrupt라고 한다). 그러면 processor는 이 신호를 감지하고 커널 영역으로 뛰어 들어간다. 커널 영역에는 device에 도착한 data를 메모리로 읽어 오고, 그 data를 사용할 process에 맞게 적절하게 형태를 바꾸어, data를 기다리는 process에게 전달하고, 그 process를 wait queue에서 꺼내 ready queue로 집어넣은 후, ready queue로 들어간 process의 우선순위가 현재 수행 중이던 process의 우선순위보다 클 경우 process scheduling을 요청한 후 process scheduling을 수행하는 일련의 명령들이 있다. 이러한 명령들에 따라 결국 processor는 device로부터 data를 읽기를 요청한 process를 다시 선택해 수행하기 시작한다. processor는 다시 시작한 process의 커널 영역에서 사용자 영역으로 빠져 나가 사용자 영역을 계속해서 수행한다.
[그림 1]을 보면서 좀 더 구체적으로 이해해 보자. process P1은 사용자 영역의 A 부분에서 system call을 통해 커널 영역으로 들어간다. 커널 영역의 B 부분에서 device로부터 data를 읽기를 요청한 후 현재 수행중인 process를 wait queue에 넣는다. 그리고 C 부분에서 process scheduling을 수행한다. 이 부분을 좀 더 자세히 들여다보면 C 부분에서 시작한 process scheduling은 D 부분에서 끝나지 않고 process P2의 E 부분에서 끝난다. 즉, c 지점으로 들어가서 e 지점으로 나온다.
process scheduling
여기서 process scheduling의 동작을 좀 더 구체적으로 살펴보자. process scheduling은 크게 두 동작으로 나뉜다. 처음 동작은 새로 수행할 process를 선택하는 부분이다. 두번째 동작은 현재 수행하고 있는 process의 상태를 저장한 다음 새로 수행할 process의 상태를 복구하는 것이다. 이 동작을 우리는 문맥 전환이라고 한다. processor는 내부에 여러 개의 register를 가지고 있으며, 이 register를 이용해 process를 수행해 나간다. register는 memory와 같이 data를 저장하는 기능을 하지만, 접근 속도가 memory보다 빠르다. 따라서 비용상 그 개수가 많지는 않다. register는 processor architecture에 따라 R0, R1, ... 또는 EAX, EBX, ... 등의 이름을 가지며, 32 bit RISC processor의 경우 일반적으로 32 bit의 크기를 갖는다. processor는 register와 memory 또는 I/O device내의 register간에
data를 옮겨가면서 procss를 수행해 나간다. 따라서 process를 수행해 나감에 따라 register의 내용은 계속 바뀌게 된다. 문맥 전환 부분을 좀 더 자세히 들여다 보면 processor가 현재 process를 수행해 나가다 어느 순간에 register의 내용을 그대로 메모리에 저장한다. 새로 수행할 process의 경우도 현재 process처럼 이전에 저장한 register의 내용이 메모리에 있으며, 따라서 그 메모리에 저장한 register의 내용을 다시 processor의 register로 복구 시킨다. 그리고 새로운 process를 계속 수행해 나간다.
문맥 전환(context switching)
문맥 전환 부분을 좀 더 구체적으로 이해하기 위해 process scheduling의 동작을 다음과 같이 가정해 보자. 처음 동작에서 새로 수행할 process를 뽑았는데 그 process가 현재 수행하고 있던 process였다. 그러면 두 번째 동작은 다음과 같이 될 것이다. processor가 현재 process의 register의 내용을 메모리에 저장한다. 그리고 방금 전에 메모리에 저장한 register의 내용을 다시 processor의 register로 복구 시킨다. 그리고 현재 process를 계속 수행한다. 이럴 경우 [그림 1]에서 C 부분에서 시작한 process scheduling은 D 부분에서 끝나며, 논리적으로 process scheduling을 수행하지 않은 것과 같다. process scheduling의 본래 목적은 process간의 전환이며 따라서 현재 process와 새로 수행할 process가 있어야 그 본래 기능을 수행할 수 있다. 여기서는 문맥 전환의 동작을 이해하기 위하여 이와 같은 가정을 한 것이다.
[그림 1] system call과 hardware interrupt에 의한 커널의 구체적인 동작
그러면 process scheduling의 본래 기능으로 다시 돌아가 문맥 전환을 생각해 보자.
[그림 1]에서 현재 process를 P1, 새로 수행할 process를 P2라 하자. 그러면 process P1의 C 부분에서 시작한 process scheduling이 논리적으로 D 부분에서 끝나야 하는 것처럼(여기서는 실제로 J 부분에서 끝난다) 이전에 process P2의 F 부분에서 시작한 process scheduling은 논리적으로 E 부분에서 끝나는 것이다. 그러나 시간상으로는 process P1의 C 부분에서 시작한 process scheduling은 process P2의 E 부분에서 끝난다. 즉, c 지점으로 들어가서 e 지점으로 나온다.
이후에 process P2에서 process P3로(f에서 g로), process P3에서 process P4로, 몇 번의 process scheduling이 더 있을 수 있으며(h에서 … i로), 어느 순간 임의의 process Pn이 수행 중일 수 있다. [그림 1]에서 process Pn을 수행하는 중에 G 부분에서, process P1의 B 부분에서 data를 읽기를 요청한 device로부터, hardware interrupt가 들어올 수 있다. 그러면 process Pn은 G 부분에서 커널 영역으로 들어간다. 커널은 H 부분에서 device에 도착한 data를 메모리로 읽어 오고, 그 data를 사용할 process P1에 맞게 적절히 형태를 바꾸어 process P1에게 전달하고, process P1을 wait queue에서 꺼내 ready queue로 넣은 후, 새로이 ready queue로 들어간 process P1의 우선순위가 현재 수행 중인 process Pn의 우선순위보다 클 경우 process scheduling을 요청한다. 그러면 I 부분에서 process scheduling을 수행한다. process Pn의 I 부분에서 시작한 process scheduling은 process P1의 J 부분에서 끝난다. 덧붙이자면, process P1의 C 부분과 J 부분은 시간적으로는 연속이지 않지만 논리적으로는 연속이다.
hardware interrupt에 의한 커널의 일반적인 동작
이제 hardware interrupt에 의해 시작한 커널의 일반적인 동작을 정리해 보자.
[그림 1]에서 process Pn을 수행하는 중에 들어온 hardware interrupt에 의해 시작한 커널의 동작은 다음과 같다.
1. device에 도착한 data를 메모리로 읽어 온다.
2. data를 사용할 process에 맞게 적절하게 형태를 바꾼다.
3. data를 기다리는 process에게 전달하고 process scheduling 요청
4. process scheduling을 수행
여기서 커널의 동작은 크게 세 부분으로 나눌 수 있으며, 그 처음 부분은 다음과 같다.
1. device에 도착한 data를 메모리로 읽어 온다.
이 부분은 hardware interrupt를 처리하는 부분으로써 신속하게 device로부터 data를 읽어냄으로써 빠른 시간 내에 device가 외부로부터 다시 data를 받을 수 있게 한다. 일반적으로 이 부분에서는 또 다른 device로부터 오는 hardware interrupt를 허용하지 않음으로써 신속하게 device로부터 data를 읽어낸다. 리눅스 커널에서는 이 부분을 top half라고 하기도 하고 interrupt handler라고도 한다.
다음으로 두 번째 부분은 다음과 같다.
2. data를 사용할 process에 맞게 적절하게 형태를 바꾼다.
3. data를 기다리는 process에게 전달하고 process scheduling 요청
이 부분은 기본적으로 hardware interrupt를 허용함으로써 응답성을 좋게 한다. 이 과정은 device에서 읽어온 data를 적당하게 처리해 그 data를 기다리는 process에게 전달하고 필요시 process scheduling을 요청한다. 리눅스 커널에서는 이 부분을 bottom half라고도 하고, deferred work라고도 하고, softirq라고도 한다. 덧붙이자면 3번 동작을 리눅스 커널에서는 wake_up이라고 한다.
마지막으로 세 번째 부분은 다음과 같다.
4. process scheduling을 수행
이 부분은 두 번째 부분에서 process scheduling을 요청할 경우 수행한다. 리눅스 커널에서는 이 부분을 schedule이라고 한다.
이상에서 hardware interrupt에 의한 커널의 동작은 [그림 2]와 같다.
[그림 2] hardware interrupt에 의한 커널의 일반적인 동작
[그림 1]에서 한 가지 주의할 점은 process Pn의 사용자 영역을 수행하는 중에 들어온 hardware interrupt에 의해 시작한 커널의 동작은 process Pn과 논리적으로 관련이 없다. 따라서 앞에서 설명한 처음 동작과 두 번째 동작을(top half와 bottom half를) 수행하는 중에 현재 process Pn은 논리적으로 멈출 일이 없으며, 따라서 wait queue에 들어갈 일은 없다.
top_half, bottom_half와 system call function간의 통신
마지막으로 한 가지만 더 짚고 넘어가면, [그림 1]에서 process P1의 system call에 의해 시작한 커널과 process Pn의 사용자 영역 수행 중에 발생한 hardware interrupt에 의해 시작한 커널은 각각 논리적으로 독립된 흐름을 가지며 B 부분과 H 부분에서 통신을 한다. 즉, H 부분에서 data를 공급하며, B 부분에서 data를 소비한다. [그림 3]은 [그림 1]의 system call에 의한 커널과 hardware interrupt에 의한 커널간에 data를 주고 받는 상황을 논리적으로 표현한 것이다.
[그림 3] top_half, bottom_half와 system call function간의 통신
system call에 의한 커널의 구체적인 동작 2
[그림 4]를 보면서 다음의 내용을 이해해 보자.
P1, Pn이라 하는 두 process가 있다고 가정하자. process P1는 system call([그림 4]의 A 부분)을 통해 커널에게 process Pn으로부터 data를 받기를 요청할 수 있다. 그러면 커널은 Pn으로부터 P1에게 도착한 data가 있는지 검사한다([그림 4]의 B 부분). P1에게 도착한 data가 없을 경우 커널은 현재 수행중인 process P1을 잠시 멈추기 위해 wait queue에 넣는다([그림 4]의 B 부분). 왜냐하면 process Pn으로부터 data가 도착해야 process P1을 다시 진행할 수 있기 때문이다. 그리고 새로운 process를 선택해([그림 4]의 C 부분) 수행하기 시작한다. 이 동작을 우리는 앞에서 process scheduling이라 했다. 그 이후에 몇 번의 process schduling이 더 있을 수 있다. ([그림 4]에서 process P2에서 process P3로)
[그림 4] system call에 의한 커널의 구체적인 동작
system call에 의한 커널의 구체적인 동작 3
어느 순간 process Pn은 process scheduling에 의해 다시 시작하며([그림 4]의 D 부분) 사용자 영역을 수행하다 system call을 통해([그림 4]의 E 부분) 커널에게 process P1에게 data를 보내기를 요청할 것이다. 그러면 커널은 process Pn으로부터 process P1으로 data를 전달하고([그림 4]의 F 부분), process P1을 wait queue에서 꺼내 ready queue로 넣은 후, ready queue로 새로이 들어간 process P1의 우선순위가 현재 수행 중이던 process Pn의 우선순위보다 클 경우 process scheduling을 요청한 후([그림 4]의 F 부분) process scheduling을 수행한다. process scheduling은 [그림 4]의 G 부분에서 시작해 H 부분에서 끝난다. 즉, process scheduling이 끝나면 process P1이 수행을 다시 시작한다.
system call에 의한 커널의 일반적인 동작
이제 system call에 의해 시작한 커널의 일반적인 동작을 정리해 보자. 먼저 system call은 software interrupt라고도 한다. 주의할 점은 software interrupt는 리눅스 커널내의 bottom half의 또 다른 이름인 softirq와는 관련이 없다.
[그림 1]에서 process P1을 수행하는 중에 들어온 system call에 의해 시작한 커널의 동작은 다음과 같다.
1. device로부터 data를 읽기를 요청한다.
2. 현재 수행중인 process를 wait queue에 넣는다
3. process scheduling을 수행
이 부분은 process의 요청에 의해 커널이 수행하는 영역이며, 상황에 따라 현재 process를 논리적으로 더 이상 진행시킬 수 없는 경우 현재 process를 wait queue에 넣고 process scheduling을 수행할 수 있다. 이 부분은 system call 함수의 일부분이다. 2, 3번 항목은 리눅스 커널의 sleep_on 또는 wait_event와 대응한다.
[그림 4]에서 process P1을 수행하는 중에 들어온 system call에 의해 시작한 커널의 동작은 다음과 같다.
1. process Pn으로부터 도착한 data가 있는지 검사한다.
2. 현재 수행중인 process를 wait queue에 넣는다.
3. process scheduling을 수행
이 부분도 process의 요청에 의해 커널이 수행하는 영역이며, 상황에 따라 현재 process를 논리적으로 더 이상 진행할 수 없는 경우 현재 process를 wait queue에 넣고 process scheduling을 수행한다. 이 부분도 system call 함수의 일부분이다. 여기서도 2, 3번 항목은 리눅스 커널의 sleep_on 또는 wait_event에 대응한다.
[그림 4]에서 process Pn을 수행하는 중에 들어온 system call에 의해 시작한 커널의 동작은 다음과 같다.
1. process P1에게 data를 전달하고 process scheduling 요청
2. process scheduling을 수행
여기서는 커널의 동작을 두 부분으로 나눌 수 있으며, 처음 부분은 다음과 같다.
1. process P1에게 data를 전달하고 process scheduling 요청
이 부분은 process의 요청에 의해 커널이 수행하는 영역이며, system call 함수의 일부분이다. 이 부분은 리눅스 커널의 wake_up에 대응한다.
두 번째 부분은 다음과 같다.
2. process scheduling을 수행
이 부분은 처음 부분에서 process scheduling을 요청할 경우 수행한다.
이상에서 system call에 의한 커널의 동작은 [그림 5]와 같다.
[그림 5] system call에 의한 커널의 일반적인 동작
[그림 5]에서 process scheduling(1)은, 현재 process P의 요청에 따라 커널이 process P와 관련된 작업을 수행하는 도중에 어떤 조건이 맞지 않아, 예를 들어 필요로 하는 data가 없어서, 더 이상 현재 process P의 작업을 진행할 수 없을 경우, 필요로 하는 조건이 맞을 때까지 현재 process P를 wait queue에 넣어 기다리게 하고 나서 수행하는 process scheduling이며, system call function내에서 수행을 한다. 한 가지 기억해야 할 점은 [그림 1]에서 C와 J 부분이 일반적으로 논리적으로는 연속이지만 시간상으로는 연속이 아니듯이 [그림 5]의 process scheduling(1)도 일반적으로 논리적으로는 연속이지만 시간상으로는 연속이 아니다. 후에 process P가 필요로 하는 조건이 맞으면, process P는 논리적인 흐름이 다른 커널(예를 들어, [그림 1]의 H 부분과 같은)에 의해 ready queue로 옮겨지며, 역시 논리적인 흐름이 다른 커널에서 시작한 process scheduling(예를 들어, [그림 1]의 I 부분과 같은)에 의해 [그림 5]의 process scheduling(1)로 나와 system call function의 나머지 부분을 수행한다. system call function 내에서는 이후에도 필요에 따라 process scheduling이 더 있을 수 있다. 이와는 달리 process scheduling(2)는 커널이 process P의 요청에 의해 system call function을 수행하는 도중에 wait queue에서 기다리던 임의의 process를 ready queue로 넣고, 그 ready queue에 넣은 process의 우선 순위가 현재 process P의 우선 순위보다 클 경우(예를 들어 [그림 4]의 F 부분과 같은)에 수행하는 process scheduling이다. 이 경우 현재 process P는 ready queue에 그대로 남아 있다.
system call function과 system call function간의 통신
마지막으로 한 가지만 더 짚고 넘어가면, [그림 4]에서 process P1의 system call에 의해 시작한 커널과 process Pn의 system call에 의해 시작한 커널은 각각 논리적으로 독립된 흐름을 가지며 B 부분과 F 부분에서 통신을 한다. 즉, F 부분에서 data를 공급하며, B 부분에서 data를 소비한다. [그림 6]은 [그림 4]의 system call에 의한 커널간에 data를 주고 받는 상황을 논리적으로 표현한 것이다.
[그림 6] system call function과 system call function간의 통신
process scheduling의 시작과 끝
우리는 [그림 2]와 [그림 5]에서 커널의 일반적인 동작과 process scheduling이 언제 수행되는지 보았다. 아래 [그림 7]에서 process scheduling이 시작되는 부분과 끝나는 부분이 어떻게 연결될 수 있는지 자세히 살펴 보자.
어떤 process의 a 부분에서 시작한 process scheduling은 임의의 다른 process의 b, d, f부분에서 끝날 수 있다. 또 어떤 process의 c 부분에서 시작한 process scheduling도 임의의 다른 process의 b, d, f 부분에서 끝날 수 있다. 마지막으로 어떤 process의 e 부분에서 시작한 process scheduling 역시 임의의 다른 process의 b, d, f 부분에서 끝날 수 있다.
[그림 7] process scheduling의 시작과 끝
지금까지 우리는 커널이 수행해야 할 일반적인 동작이 무엇인지 살펴 보았다. 즉, system call을 통해 시작한 커널의 동작, hardware interrupt에 의해 시작한 커널의 동작을 보았다. 이 과정에서 process와 device 사이에서 커널이 수행해야 할 역할이란 것이 우리가 모르는 그 어떤 것이 아니란 점도 느꼈을 것이다. 의외로 커널의 역할이 지극히 당연한 것들이라고 느꼈을 수도 있다. 또 hardware interrupt에 의해 시작한 커널과 system call에 의해 시작한 커널간의 통신, system call에 의해 시작한 커널과system call에 의해 시작한 커널간의 통신을 보았다. 이 과정에서 논리적으로 서로 독립적인 커널의 동작간에 통신이 어떻게 이루어지는지 구체적으로 알았을 것이다.
서민우 / minucy@hanmail.net
과학기술정보연구소 및 여러 대학교에서 임베디드 리눅스 실무과정을 강의하면서 리눅스 커널 초기버전을 분석하는 작업을 통해 초보자들도 OS 의 설계 및 구현에 대해 체계적으로 접근할 수 있는 방법에 대한 자료를 제작하는 데에 힘을 쏟고 있다. 50개 정도의 명령어, pipeline 등을 포함한 32 bit RISC CPU 를 설계 및 구현한 경험이 있고 uCOS/II 정도 수준의 OS 설계 및 구현에 대한 체계적인 접근 방법에 대한 자료까지 완성한 상태이며 지속적인 작업을 통해 커널과 OS에 관한 유용한 정보를 널리 공유하고자 노력하고 있다.
TAG :
이전 글 : ASP.NET 가이드 1. 자바 스크립트 사용하기
다음 글 : 소스 코드 공유를 위한 패턴
최신 콘텐츠