※ 질문/내용오류/공유할 내용이 있다면 jinkilee73@gmail.com으로 메일 주세요 :-)

Context Switching을 공부해보자. 우선 설명을 하기 전에 밑에서 사용할 예제는 임베디드 관련 유명 블로거이신 히언님의 블로그에서 따온 것임을 먼저 알려드리께요.

[Reference] http://recipes.egloos.com/

이 블로그의 다음 글을 읽고 제 글을 읽어주시길 바래요. 그래야 이해가 쉬울 거에요.

[Reference] http://recipes.egloos.com/4986854

앞서 말했듯이, Context Switching은 현재 동작하고 있는 프로세스의 CPU 레지스터 값을 메모리 스택에 저장하는 과정이다. 이렇게 저장된 값을 가지고 나중에 값을 불러내면 프로세스가 돌아가고 있던 예전의 그 시점부터 다시 실행시킬 수 있게 된다.

전체적인 과정은 위와 같다. 우선, PUSH를 통해 스택에 모든 레지스터 값들을 집어 넣는다. (레지스터값은 번호가 매겨져있다. R14부터 R0까지, 단 R13은 특별한 이유로 제외,의 값을 저장한다.) 그리고 스택 포인터를 새로운 값으로 업데이트 하여 나중에 그 스택 포인터 값으로 돌아가서 이전의 값들을 불러온다.

Context Switching의 과정을 자세하게 들여다보자. Context Switching을 하기 전의 스택 상태와 메모리 상태가 다음과 같다고 하자.

위에서 저장해야할 값들은 R0부터 R14까지이다. 단, R13은 제외. 이 값들을 메모리의 스택에 저장해야 한다. (위의 그림에서는 가장 오른쪽에 열에 나와있다.) 저장하기 전의 스택은 다음과 같은 값을 보인다.

빨간 화살표가 가리키고 있는 저 위치가 현재 스택 포인터가 가르키는 주소이다. 이 위치 이전 주소부터 낮은 주소 방향으로 스택을 저장하기 시작한다. (01141E88 → 01141E84 → 01141E80 → ...이 방향으로) 

R14는 0B49 ..... R0은 01E4

이와 같은 값을 가지고 있으니까, context를 저장하고 나면 다음과 같은 형태가 된다.

위와 같이 스택의 값이 바뀌고 스택 포인터가 가리키는 값도 바뀌게 되었다. (01141E80 → 01141E4C)

이때, 주의할 것은 R14값인 B49는 linked register(lr)이라고 하는데, 이 값은 새로운 프로세스가 동작할 때, 현재의 스택 포인터 값으로 업데이트된다. 즉, 위의 상황에서 R14 레지스터의 값은 01141E8C가 된다.

※ linked register : JUMP 명령어를 수행하기 이전의 값을 가지고 있는다. 즉, 후에 original address로 돌아오기 위한 레지스터이다.

그 다음에 CPU에서는 이상한 다른 프로세스들이 돌아가기 시작할 것이다. 그 프로세스도 CPU 점유권을 잃고 context saving을 한 후 다시 이전 프로세스의 context를 불러오게 될 것이다.(context restore)

어떻게 복구할까?

Idea는 간단하다. 우리는 linked register 값만 알면 복구할 수 있다. linked register가 가리키는 값에서 우리는 점프를 했으니까, 그 값만 알면 원래의 주소로 돌아갈 수 있다.

이 값은 R14에 저장되어있다고 위에서 설명했다. 그렇다면 이 값은 어떻게 알까? 그림으로 보면 더 쉬우려나?

위 과정은 전체적인 Context Switching 과정이다. 즉, 스택 포인터를 통해서 R0으로 접근하고 R0부터 차례대로 거슬러 올라가서 R14를 알아낸 후, 그 지점으로 점프한 후, R0 ~ R14를 CPU register에 저장한 후 이전의 프로세스를 다시 시작하면 된다.

(※ 여기서, 스택 포인터가 애초에 0x000055CD를 가리키고 있었던 이유는 무엇일까? 이전에 T2에 대한 context saving 과정에서 스택 포인터 값이 업데이트되었기 때문이다.)

아마 처음 본 사람들은 이해하기가 매우 어려울 거에요. 6개월 전에 이걸로 프리젠테이션을 했던 저도 다시 보니까 아리까리 하네요. 다음 포스팅에서는 더욱 쉽게 설명해보려고 노력해볼게요.

※ 질문/내용오류/공유할 내용이 있다면 jinkilee73@gmail.com으로 메일 주세요 :-)

Job Queue, Ready Queue 그리고 Device Queue에 대해서 이야기해보자.

Job Queue

Job Queue를 설명하기 전에 논해야 할 것은 long-term 스케줄러이다. 위키피디아에 따르면, Job Queue는 다음과 같다.

In system software, a job queue (sometimes batch queue), is a data structure maintained by job scheduler software containing jobs to run.

[Reference] Wikipedia (http://en.wikipedia.org/wiki/Job_queue)

job scheduler에 의해 유지되는 data structure라고 한다. 그런데, job scheduler = long-term scheduler이므로 job queue는 secondary storage에 있는 프로세스가 메모리로 load될 때 secondary storage에 형성되어있는 큐라고 볼 수 있다.

Ready Queue

Ready 상태에 있는 프로세스들, 즉 메모리에 load되어있는 프로세스들이 ready queue에 쌓여있는다. 따라서, ready queue는 메모리에 load되어있는 queue라고 할 수 있다.

device queue

ready queue가 메모리에 있다면 device queue는 device controller에 있다. device controller는 쉽게 말해서 하드웨어 그 자체이다.

http://www.tomshardware.com/reviews/cpu-stress-test,942-5.html

위에 보이는 USB가 꽂혀있는 저 쇠덩어리가 usb controller이다. 즉, 모든 I/O device들이 controller들이고, 각각의 controller들은 당연히 buffer를 가지고 있다. 그 device queue는 그 buffer에 임시적으로 저장된다.

이번 포스팅에서는 전전 포스팅에서 설명했던 

프로세스 상태(http://operatingsystems.tistory.com/entry/OS-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EA%B4%80%EB%A6%ACProcess-Management)를 위에서 설명한 각각의 queue들과 같이 설명을 하고 싶다.

위에서 말했듯이, 아래의 과정에서는 long-term 스케줄러가 개입하게 된다. 

이 때, long-term 스케줄러는 secondary storage에 저장되어있는 Job queue로부터 프로세스를 끌어와서 메모리에 load시킨다.

ready 상태에 있는 PCB1은 CPU 스케줄러에 의해 CPU 점유권을 갖게 된다. 그 후 아래와 같이 PCB1 내부에 있는 우선순위가 다른 PCB의 우선순위보다 높으면 CPU 점유권을 갖게 된다. CPU 점유권을 가지고 있는 상태에서 I/O request가 들어오면 해당 PCB1은 CPU 점유권을 잃고 device controller 안에 있는 buffer의 device queue로 들어가게 된다. 그러면 다음과 같은 상태가 된다.

PCB1이 ready queue에서는 삭제되었음을 볼 수 있다. (만일 ready queue에서 삭제가 안 된다면, 이게 queue가 아니지?! 안 그런가?) 이 상태에서 I/O 작업이 모두 끝나면 다시 ready queue로 들어간다. 

위와 같은 상황이 asleep 상태에서 ready 상태로 돌아간 상태이다. I/O 작업이 끝났다는 말이 device queue에서 쫓겨날 때가 됐다는 뜻이고, ready queue로 다시 돌아갈 때가 됐다는 뜻이기도 하다.

한 가지 주의하자. running 상태에서 asleep 상태로 갈 때 PCB 정보들은 ready queue에서 사라지고 device queue로 간다. 그렇다면, 다음에 I/O 작업이 끝난 후, ready 상태에서 running 상태로 갈 때, 이전에 수행했던 값들은 어떻게 가지고 올까? 이 개념이 context switching이다. 애초에 running 상태에서 asleep 상태로 갈 때 OS는 context switching이라는 작업을 통해서 현재 이 프로세스의 context(register values)를 메모리에 저장해둔다.

다음 포스팅은 context switching에 대해서 자세하게 이야기해보자.

※ 질문/내용오류/공유할 내용이 있다면 jinkilee73@gmail.com으로 메일 주세요 :-)

스케줄러에 대해서 이야기해보자.

이전의 포스팅에서 말했듯이, 스케줄러는 메모리에 있는 여러 프로세스 중에서 어떤 하나의 프로세스가 CPU 점유권을 가질지를 정해주는 것이다. 스케줄러는 세 가지 종류가 있다.

Long-term 스케줄러 (Job scheduler)

하드 디스크에서 메모리로 프로세스를 load하는 역할을 한다. 즉, 다음의 과정에서 long-term 스케줄러가 동작한다.

Short-term 스케줄러 (CPU scheduler)

메모리에 있는 프로세스 중에서 프로세스가 CPU 점유권을 가질 때 어떤 프로세스가 선택되는지를 결정하는 스케줄러이다. 다음과 같은 과정에 동작한다.

Midium-term 스케줄러

asleep 상태에서 ready 상태로 넘어가지 못 하거나 ready 상태에서 running 상태로 넘어가지 못 하는 상황이 발생하면 어떤 일이 벌어질까? 결과적으로 실행되지도 않으면서 메모리만 차지하고 있는 비효율적인 상황이 발생한다. 이럴 경우 메모리에 load되어있는 running 상태로 넘어가지 않는 프로세스를 하드디스크로 쫓아낸다.(swap-out) 그리고 나중에 필요에 의해 다시 메모리로 들어올 수도 있다.(swap-in) 즉, 아래와 같은 과정이다. 이 과정을 midium-term 스케줄러가 한다.

스케줄러에 대한 설명은 여기까지이다. 다음 포스팅에서는 Job Queue, Ready Queue 그리고 Device Queue에 대해서 논해보자.