Professional Linux Kernel Architecture - Chapter 2, Introduction ~ 2.1

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에 의존적이지 않다.(알고리즘에 결정된다는 뜻?)

□ process A에서 process B로 교체가 될 때, process B가 CPU 자원을 마지막으로 놓았던(release) 시점의 환경과 동일해야 한다.(당연한 얘기지만 B가 수행되었던 자원 등 상태를 어딘가에 저장해두어야 한다는 의미인듯) 예를 들어, CPU register 값과 virtual address의 구조등의 것들이 교체된 process가 가지고 있었던 것이어야 한다. 

후자의 내용은 CPU type에 매우 의존적이다.(가상 메모리의 구조나 cpu의 register 운영은 cpu architecture 마다 다른게 가지고 있다)그것은 C 언어 만으로 구현되기 어려우며 architecture의 assembler 에 도움을 받아야한다. (register 내용을 저장하고 복구하는 내용들은 순수 assembler로 구현되어 있다)

위의 두가지 작업은 scheduler라는 kernel의 subsystem이 관장하고 있다. scheduler 정책에 의해 각 process에게 CPU 시간을 할당하고 수행하게 한다. 이것은 process 교체 메카니즘과는 완전히 분리된 작업인 것이다. (task switch 관련해서는 다른 포인트인 듯)

2.1 Process Priorities

모든 process들이 똑같이 중요한 것은 아니다. process 우선순위는 여러 요구사항을 만족시키기 위한 임계점(Criticality classes)이 다르다. 임계점을 고려하는 부분에서 크게 두 분류로 나누어 보면, real time process와 non-real time process가 있다. 

□ Hard real-time process는 Process가 수행 완료되는 시간이 엄격히 제한적이다. 만약 항공기의 비행 조종 명령이 컴퓨터에 의해 처리된다면, 그 명령들은 최대한(물론 최대한이라고는 하지만 dead line이내에 수행이 되어야 한다는 뜻) 빨리 기계에 전달되어야 한다. 예를 들어, 만얀 항공기가 착륙지점에 다달았고, 조종사는 기수를 끌어내리기를 시도할 때, 컴퓨터가 몇초 늦게 명령을 전달하여 그 작은(?) 일을 진행했다. 그 때, 항공기는 아마도 땅에 뭍혀버리고 말것이다. Hard real-time process의 중요한 key point는 보장된 시간내에 그 명령이나 행동을 무조건 처리해야한다. 물론 이 보장된 시간은 특별히 짧은 시간만을 말하는 것이 아니다. 그 보다 더 시스템은 주어진 시간을 절대로 초과하지 않는다는 것을 보장해야 한다. 

Linux는 hard real-time processing을 지원하지 않는다.(적어도 vanilla kernel에서는..) 그렇지만, 수정된 리눅스 버전에서 지원되고 있다(RTLinux, Xenomai, RATI 등). 수정된Linux는 process를 분리하여 수행한다. 이는 kernel이 덜 중요한 software(process)를 real-time process 작업이 kernel 외부에서 수행되는 동안 처리하도록 한다.

Linux는 throughput(처리량)을 위해 최적화 되어 있고 가능한한 일반적인 경우를 처리하려고 노력한다. Linux에서는 보장된 응답 시간을 맞추는 것은 어려운 일이다. 그럼에도 불구하고 kernel 전체의 지연시간(요청하고 이행하는 사이의 시간)의 감소는 아주 조금씩 진전이 있어왔다. 이런 진전은 preemptible kernel mechanism(선점 커널 메카니즘), real-time mutexes, 새로운 completely fair scheduler 등으로 이루어 졌다. 이 책의 뒷 부분에 더 자세히 설명되어 있다. 

□ Soft real-time process는 hard real-time 보다 덜 강압적인(?) 형태이다. 비록 빠른 결과를 요구되는 것은 변함이 없지만, 조금 늦게 처리 된다고 하더라도 문제 될 것이 없는 것이다. CD에 data 쓰기를 하는 작업을 예로 들 수 있다. Data는 반드시 CD writer에게 연속적으로 기록해야하는 매체인 만큼 정해진 비율로 지속적으로 전달되어야 한다. 만약 시스템의 부하가 높아져서 Data 전송에 방해를 받게 된다면, CD를 사용할 수 없게 될 수도 있다. (이것은 위에 hard time의 예로 들은 비행기 추락보다는 낫다는 얘기이다). 이것 때문에라도(CD 를 못쓰게 하는 것을 방지) CD write process는 다른 process보다 그것이 요구하는 시간만큼 보장을 받게 해준다.

□ 대부분의 Process들은 특별한 시간 제한이 없는 "normal process"이다. 하지만 그것들에게 더 중요하고 덜 중요하다는 의미의 우선순위로 분류 하고 있다. 

예를 들면, 긴 시간의 컴파일 작업과 숫자 계산을 하는 process는 상대적으로 매우 낮은 우선순위는 가진다. 이유는, 1초 혹은 2초 동안 때때로 진행을 방해받더라도 결과에는 영향을 거의 미치지 않기 때문이다. 반대로 대화형 application(VIM 같은 편집기)는 가능한 빠르게 사용자 명령에 대한 응답을 보내줘야하기 때문에(사용자는 인내심이 없기로 유명하덴다) 높은 우선순위를 가진다. 

application의 CPU 시간은 그림 2-1에서 간단하게 보여 줄 수 있다. Process들은 하나의 시간 조각(time slice)에 나누어 위치하고 있고 각각 중요도에 따라 조각의 크기는 다르게 설정된다. 시스템의 시간 흐름에 따라 원을 돌며 Process를 실행하고 모든 process가 수행되기는 하지만, 중요한 Process들은 상대적으로 많은 시간을 얻어 수행시간이 길다. 

<그림 2-1>

선점 멀티태스킹(preemptive multitasking)이라고 알려진 방법은, 각 process는 수행되는 일정한 시간을 할당 받는다. 일단 그 시간이 만료되면, kernel은 process로 부터의 control을 그만두고 다른 process를 수행시킨다(여기서 다른 process는 이전 process에 의해 마지막으로 실행된 작업과는 무관하다). 시간의 만료된 process의 환경(특히, CPU register와 page table의 내용)은 꼭 저장되어 나중에 다시 복귀하여 실행 시 완전히 이전 상태로 돌아갈 수 있어야 한다. time slice의 길이는 process의 중요도에 따라 다르게 정해지게 된다. 그림 2-1과 같이 각각의 process들은 다른 크기의 slice를 가지고 있는 것을 확인 할 수 있을 것이다. 

이 단순화된 모델(그림 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 을 마무리 합니다. 틈틈히 읽어보고 수정사항이 있다면 변경하도록 하겠습니다.