Operating System: ch1. Introduction to OS

Evolution of OS

Operating System(OS)을 한마디로 정의하기란 어렵다. 왜냐하면 과거서부터 여러 문제를 해결하기 위해서 OS라는 개념이 계속 바뀌었기 때문이다. 따라서 OS의 발전역사를 짚어보면서 시대마다 OS의 정의가 어떻게 변화했는지 살펴보고자 한다.

  • Phase 1
    1. Early Systems (1950년대)
    2. Simple Batch Systems (1960년대)
    3. Batch Monitor (1960년대)
    4. Multiprogrammed Batch Systems (1970년대)
  • Phase 2
    1. Time-Sharing and Real-Time Systems (1970년대)
    2. Personal/Desktop Computers (1980년대)
    3. Multiprocessor Systems (1980년대)
    4. Networked/Distributed Systems (1980년대)
  • phase 3
    1. Web-based Systems (1990년대)

Phase 1: 50년대 초반 ~ 60년대 중반

이 시기에는 하드웨어는 비싸고 인건비는 저렴했다. CPU의 utilization을 최대화하는게 목적이었다.

1-1 Early Systems: Operator as OS

Human Operator가 단순히 program loader로써 OS의 역할을 했었다. 사실상 운영체제는 없던 시기이다. job이라고 하는 연산처리단위(프로그램 최소 실행 단위)가 펀치카드에 입력되면, 카드리더라는 장치로 빛을 쏘아 빛이 투과된 패턴을 보고 글자(character)를 읽는 방식이다. 가장 초창기 Human Operator의 역할은 다음과 같았다.

  1. 사용자로부터 카드 덱(일종의 job) 수령
  2. 카드 덱을 컴퓨터 시스템에 로딩하고 수행
  3. 수행 결과를 CPU가 프린터로 출력
  4. 출력된 결과물을 사용자에게 전달

당시 컴퓨터의 CPU가 트렌지스터가 아니라 진공관 형태였어도 전자적인 장치였기 때문에 하드웨어 연산 속도는 비교적 빨랐다. 반면에 Human Operator의 작업속도가 너무 느렸다. 즉, job-to-job transition(job과 job 사이의 전환 속도)이 이때도 굉장히 느렸다.

1-2 Simple Batch Monitor

최초의 OS는 사실 이때 등장한다. Human operator의 slow job-to-job transition으로 인한 컴퓨터시스템의 비효율성을 해결하기 위해서 batch monitor가 등장한다.

image 슬라이드 출처

Batch monitor에서 Batch란 ‘동일한 속성의 요소들의 묶음’을 뜻한다. 대표적인 예로 IBM 1401라는 모델이 있다. 이 모델에서는 batch monitor방식을 적용하여 job-to-job transition을 빠르게 할 수 있었다.

  1. 사용자가 펀치카드와 같은 오프라인 장치에서 작업을 저장
  2. 여러 사용자로부터 human operator가 카드 덱(batch of jobs) 수령
  3. 카드 덱을 컴퓨터에 제출
  4. 메인 컴퓨터가 바로 카드덱을 처리하지 않고 IBM 1401에 일단 준다.
  5. IBM 1401은 테이프에 저장한다. 이때 하나의 job만 저장하지 않고 여러 개의 job을 저장한다. (batch)
  6. 메인 컴퓨터는 이 테이프를 받아서 job을 처리한 후 그 결과를 다시 테이프에 저장한다.
  7. 결과가 저장된 테이프를 IBM 1401이 프린트한다.
  8. 프린트 결과를 사용자에게 전달한다.

1962년도 실화를 배경으로한 영화 <히든 피겨스>에도 당시 OS에 대한 장면이 등장한다.

마침내, Operator의 slow job-to-job transition 문제를 해결하여 CPU utilization을 높혔다. 하지만, 입출력할 때(I/O 진행되는 동안) CPU가 I/O 작업을 관리하면서 기다리는 문제가 있어서 비효율적이었다.

1-3 Batch Monitor

이러한 비효율성은 별도로 I/O 작업을 관리해주는 I/O channel을 도입함으로써 해결했다. CPU는 I/O 시작과 끝만 관리하고 그 사이에 CPU가 다른 작업을 수행할 수 있게 만들어서 효율성을 높였다. 즉, Interrupt 메커니즘을 지원하는 Batch Monitor가 등장했다. 여기서 I/O channel은 당시 IBM에서 사용한 용어이고 현대적으로는 I/O device controller라고 부른다.

image 슬라이드 출처

I/O controller가 I/O operation을 끝내면 이 결과를 CPU에게 전달하기 위해서 비동기적으로 interrupt 메커니즘을 사용한다. 이런 I/O controller라는 하드웨어의 도움으로 I/O 동작과 CPU동작이 overlap 가능해졌다.

  • I/O methods의 2가지 타입
    • Synchronous I/O (동기적 I/O): CPU가 어떤 연산을 수행하다가 I/O operation을 할때 그 연산이 종료되어야지만 다음 연산을 수행할 수 있는 것 (After I/O starts, control returns to user program only upon I/O completion)
    • Asynchronous I/O (비동기적 I/O): I/O operation을 할 때, 그 결과를 기다리지 않고도 CPU가 바로 다음 연산을 수행할 수 있는 것 (After I/O starts, control returns to user program without waiting for I/O completion)

하지만, Batch Monitor에도 한계가 존재했다. 비동기적 I/O의 경우에는 CPU Utilization을 높일 수 있지만, 동기적 I/O의 경우에는 여전히 CPU가 I/O 동안 다른 작업을 수행할 수 없기 (idle) 때문에 utilization이 낮아진다. 여태까지 CPU는 한번에 하나의 job만 처리 가능했다.

1-4 Multiprogrammed Batch Monitor

이러한 Batch monitor의 한계를 CPU가 동시에 다른 job을 함께 시작함으로써 극복할 수 있었다. Multi-programmed Batch Monitor가 탄생한 것이다.

image 슬라이드 출처

active job
수행을 시작했지만 아직 종료되지 않은 상태의 프로그램
multi-programming
컴퓨터 시스템의 메인 메모리에 동시에 여러 개의 active job이 존재하는 것
degree of multiprogramming
현재 메인 메모리에 존재하고 있는 active job의 개수

여러명의 user가 하나의 컴퓨터 시스템을 공유하게 됐다. 즉, degree of multiprogramming ≥ 1이 되었다. 당시 IBM system 360 메인프레임 컴퓨터 내에 OS 360이라는 multi-programmed batch monitor를 탑재하려고 했었는데, 불행히도 개발이 3년이나 지연됐다. 왜냐하면 새로운 기술적 문제점이 나타났기 때문이다.

문제점 1: Memory protection

C 언어에서 가장 어려운 버그가 point error이다. 기계어 프로그래밍하던 당시엔 여러 프로그램이 메모리에 상주한 상태에서, job2가 포인터 에러로 job1을 overwriting해서 프로그램 오류가 나타날 수 있었다. 심한 경우엔 OS 영역을 건드릴 수도 있었다. 그래서 어떤 job의 주소 사용 버그로 인해 다른 job이나 OS의 메모리 영역을 침범하므로써 일어나는 문제를 방지해야할 필요성이 대두됐다.

문제점 2: Memory Relocation

Multiprogrammed Batch Monitor 이전에 단일 job만 상주했을 때 메모리 특정영역에 load되어서 특정한 절대주소에 접근하여 데이터를 manipulate할 수 있었지만, 이제 job은 임의의 영역에 load되기 때문에 메모리 할당문제가 대두됐다. 기계어/컴파일러가 어느 메모리 시작주소에서 프로그램이 시작되는지 알아야 프로그램을 실행시킬 수 있다. 메모리의 임의 주소에서 job이 load되어도 프로그램이 잘 실행되어야 한다. 이러한 문제로 인해 하드웨어 수준의 메커니즘인 base register(프로그램이 로드된 시작주소를 담고 있는 주소), 소프트웨어적으로는 논리주소(CPU에서 프로그램에 의해 바로 생성되는 주소)라는 개념이 생겨났다.

Memory Management Unit(MMU)

image

문제점1과 문제점2를 해결하기 위하여 MMU(Memory Management Unit)의 초보적 형태가 Base/Bound registers로 등장했다.

base register
어떤 프로그램이 수행되는 동안 그 프로그램이 합법적으로 접근할 수 있는 메모리상의 가장 작은 주소를 보관
bound register
그 프로그램이 base register 값부터 접근할 수 있는 메모리의 범위를 보관

MMU는 이 두 가지 개념을 실현하기 위한 유닛으로 메모리 보호와 논리/물리 메모리주소 변환 등을 수행한다.

  • memory protection: Job이 사용하는 메인 메모리의 시작 주소(Base register에 저장)와 job이 사용하는 메모리의 크기 (bound register에 저장)를 사용해 현재 접근하려는 주소값이 Base register와 base register+bound register 사이에 있는지를 확인한다.
  • memory relocation: 프로그램을 작성할 때는 항상 0번지에 로드된다고 가정하고 주소값들을 계산하고, 수행 시에 주소값을 계산하기 위해서는 base register의 값을 더해서 실제 물리적 메모리의 주소를 계산
논리주소(logical address)
프로그램에 의해 CPU가 바로 생성하는 주소
물리주소(physical address)
일련의 변환을 거친 최종 메인 메모리 주소

MMU는 소프트웨어보다는 하드웨어로 구현하는게 더 낫다. 소프트웨어로 구현하면 2가지 문제가 발생한다

  1. 성능문제. redundancy가 발생한다. 하나의 instruction이 수행되려면 최소한 하나의 address가 만들어져야한다. 소프트웨어로 구현됐다는 뜻은 여러 instruction들을 추가로 필요로하며 이는 메모리를 더 잡아먹는 꼴이 된다.
  2. 좀 더 심각한문제. MMU가 소프트웨어로 구현되면 MMU역시 instructions들로 구성이 될 것이다. 이때, MMU의 주소 역시 이런 mapping과정을 거쳐야하는데 자신의 코드를 보호하기 위해 재귀적으로 호출되는 문제 발생한다.

Q. MMU는 OS관점에서 주목을 해야할까? 즉, transparent한가? MMU가 도입되면 OS는 어떤일을 해야할까?

A. MMU의 등장은 OS입장에서 transparent하지 않다! 즉, OS가 직접 조작하는 유닛이다. 왜냐하면 하나의 job이 수행되다가 다른 job으로 넘어가면 새로운 job의 base register의 값을 OS가 set해줘야한다. 또 protection을 위해서 bound register의 값도 set해줘야 한다. 또한, MMU는 일반 job말고 OS만 컨트롤할 수 있어야한다. OS만의 고유한 권한으로 수행할 수 있어야 한다. 이러한 OS만의 instruction을 privilieged instruction이라고 한다.

문제점 3: Concurrent programming

multi programming 환경에서 여러 job들이 동시에 수행하게되면, 공유자원, 공유 데이터에 동시에 접근함으로써 발생하는 문제가 생긴다. 이는 추후 synchronized programming파트에서 자세히 다룬다.

결국, 이러한 3가지 문제점들을 해결하는 과정을 통해서 점차 OS가 Computer Science 분야의 중요한 연구주제로 떠오르기 시작했다.

Phase 2: 60년대 중반 ~ 90년대 중반

하드웨어가 발달한 시기이다. 특히 트랜지스터, 집적회로가 발달하여 컴퓨터 시스템이 작고 저렴해진 시기이다. 반면에 사람의 인건비는 상대적으로 높이진 시기이다. CPU의 utilization을 최대화시키는게 여전히 목표이긴 하지만 다른 한편으로 사람의 시간을 효율적으로 사용하는 목표가 생겼다.

phase 1에서는 사람이 펀치카드로 펀칭해서 카드덱을 만든다음, operator에게 전달하면 operator가 이걸 모아서 batch로 만든 후 연산을 했다. 이때 operator가 결과를 줄때까지 가만히 기다려야 했다(idle)

이제 인건비가 비싸지니 idle해지지 않기 위해서 개개인에게 컴퓨터를 하나씩 주고 필요로 하는 시간에 얼마든지 컴퓨터를 사용하게 해야했다. 그런데 연산하는 컴퓨터 자체는 여전히 비쌌다. 그래서 고안해낸게 Terminal이다.

image 당시 가장 많았던 터미널. DEC사의 VT100 모델. 이미지 출처

Terminal란 중앙에 컴퓨터 1대만 있는 상황에서 이 컴퓨터와 연결되어 데이터를 입출력할 수 있는 하드웨어 장치를 일컫는다. 실제로 1인 1컴퓨터는 할 수 없었고, 대신 터미널을 1대씩 줬다.

하지만, 이때 문제가 발생한다. 컴퓨터, 즉 CPU는 1개 인데, 유저(터미널)은 여러명이다. 그러면 어떻게 여러명의 유저들에게 하나의 CPU를 제공하면서 interactive하게 보일 수 있을까?

2-1 Interactive Time-Sharing OS

이러한 문제를 해결하는 방식으로 하나밖에 없는 CPU의 자원 및 시간을 여러 유저들에게 쪼개서 나누어줌으로써 해결했다. 사용자에게 interactive한 통신을 수행하기 위해 시분할(Time sharing)이라는 개념이 도입됐다.

이렇게 Time sharing개념을 도입한 OS를 Time-sharing OS라고 부른다.

Time-sharing 덕분에 사용자들이 중앙컴퓨터를 자기혼자 소유하고 있는듯한 기분이 들기 시작했다. 그러면 private하게 느끼고, 자신의 개인정보를 컴퓨터 시스템에 저장하기 시작했다. 하지만 실제로 저장된 데이터는 private하지 않기 때문에, 사용자 정보, 권한 개념을 담을 수 있는 file system 개념이 만들어졌다.

여기에 더해서 컴퓨터 시스템이나 OS을 평가하는 metric도 변했다. Batch monitor시대에는 단위시간당 얼마나 많은 job을 처리하는지(=throughput)가 중요했는데, Time sharing OS에서는 사람들의 사용감이 더 중요해서 response time, 보안성 등이 평가척도로 사용되기 시작했다.

OS의 학문적인 역사를 보면 60년대 후반에 time sharing OS이 나오고 나서 70, 80, 90년대를 거치면서 대부분의 OS 중요 이론이 정립됐다.

Phase 3: 90년대 중반 ~ 현재

이 시기의 가장 큰 특징은 인터넷이 필수가 되면서 네트워크적인 개념이 도입됐다는 점이다.

3C Convergence: (1) Communication (2) Computer (3) Consumer Electronics (Connected)

3-1 OS with built-in Internet Access

이전까지는 인터넷을 하려면 TCP/IP 프로토콜 모듈을 별도로 구입해서 복잡한 방법으로 설치해야만 했었다. 그러나 이때부터 TCP/IP가 기본으로 탑재됐다. 웹 프로그래밍도 중요해졌다. 인터넷 네트워크를 통해 다른 컴퓨터와의 통신이 가능해지면서 Multitasking이 다시한번 중요해졌다.

3-2 Sophisticated PC OS

PC OS과 서버용 OS과의 경계가 없어졌다. 왜냐하면 하드웨어가 저렴해졌고 그 결과 PC에 사용되는 마이크로프로세서도 고성능, 고사양이 됐다. 이에 따라 OS도 덩달아 복잡해졌다. 그리고 인터넷 때문에 PC에서 유저 한명이어도 네트워크상으로 여러 유저가 있는 거랑 마찬가지가 되었다.

3-3 OS with Multimedia Support

스마트기기 구매 이유: 모바일커뮤니케이션+멀티미디어. 과거의 OS와 다르게 phase3에서는 멀티미디어 서포트가 굉장히 중요한 요소가 되었다.

과거에는 유니미디어, 즉 텍스트만 있었다면 이제는 멀티미디어로 미디어가 여러개 있으면서 오디오, 비디오 등도 처리해줘야했다. OS관점에서는 미디어가 많다는게 중요한게 아니라 멀티미디어는 ‘continuous’ 미디어라는 점이 사실 중요하다. 즉, 동영상처럼 특정한 시간적 제약에 맞춰 연속적으로 처리해야하는 데이터라는 의미이다(e.g., 30 frames/sec). 텍스트같은건 한번 업로드하면 뜻

  • Downloading vs. streaming
    • Downloading: 전체 데이터를 확보한 다음에 작업을 시작할 수 있다
    • Streaming: 일부 데이터만 확보한 상태에서 작업을 시작할 수 있다.

그 결과로 OS의 스케쥴링 방식도 바뀌었다. 과거에는 우선순위 기반 스케쥴링이었다면, 요즘은 continuous 미디어를 원활하게 처리하기 위한 bandwidth 스케쥴링(ex. proportional share scheduling: 필요한 cpu의 일정 bandwith를 고정적으로 할당)이 되었다.

멀티미디어는 스케쥴링을 잘못하면 human perception이 나빠지게 된다 (ex. 20년전 컴퓨터는 파일 드래그 시에 듣고있던 mpc3 음악이 버벅거리거나 끊김)

3-4 OS as Commodity

OS는 과거에는 전문적인 분야였는데 이제는 좀 더 보편적인 자원이 되었다. 이제는 누구나 관심이 많아졌다. 그만큼 기기의 중요한 요소가 됐다는 뜻.

Functions of OS

OS Characteristics

현재 OS는 크게 3가지 특징을 가진다.

  1. Large 하나의 OS가 1000만 줄의 코드가 넘어간다. 대략 100~1000 man-years에 해당되는 작업량이다. 예를 들어 1000 man-years이면 개발자 500명이 2년동안 계속 개발해야 하나의 OS가 나온다는 뜻이다.
  2. Complex 매우 Asynchronous한 시스템이다. Hardware idiosyncrasies하다. 그리고 하나의 시스템에서 여러개의 job이 수행되기 때문에 users와 performance goals 같은게 다 다르니까 needs가 conflict한다.
  3. Poorly understood 하나의 시스템 수명이 그걸 만든 builder보다 길다. 모든 걸 전부 debug하기에는 너무나 복잡하다. 그래서 자주 unreliable하다.

Functions of OS

1. Coordinator

OS이 관할하는 컴퓨터시스템에는 여러 task가 있어서 멀티태스킹해야하는데, 각 task는 자원을 필요로 한다. 서로 자원을 차지하려고 충돌하는데 이때 OS가 중재자 역할을 해야한다.

image

크게 3부분(1,2,3)으로 나뉘고, 추가로 sub system 2부분(4,5)있다.

  1. CPU 관리.스케쥴러.프로세서 매니저
    • 여러 유저들 동시에 일할 수 있도록, 하나의 유저가 동시에 여러 일을 할 수 있도록
  2. 메모리 관리
    • 메모리의 어느 부분을 사용하고, 누가 사용하는지 점검. 메모리에 저장할 프로세스를 결정, 메모리를 할당하고 회수하는 방법을 결정
  3. I/O 디바이스 매니저
    • I/O연산이 끝나면 I/O device가 CPU를 interrupt할 수 있도록 한다.
  4. 파일시스템 관리
    • 파일은 하드디스크 드라이브라고 하는 볼륨스토리지에 저장되어있는 named collection of data. 그래서 사실 파일 시스템도 하드디스크라고 하는 I/O를 관리하는 장치이다.
  5. 네트워크 시스템 관리
    • 네트워크는 사실 I/O디바이스의 일종인데 컴퓨터 시스템입장에서 네트워크라는건 ‘네트워크 인터페이스 컨트롤러’를 얘기하는거다.

Q. 파일시스템도 I/O 시스템인데 왜 따로 뺐을까?

A. 그 이유는 I/O 연산의 성능과 연관이 있다. image

Storage-device Hierarchy가 있다. 위 그림에서 아래쪽으로 갈수록 데이터 I/O 속도가 기하급수적으로 감소한다. 그래서 컴퓨터 아키텍쳐로 각 단계 사이에 Cache 메모리를 두어 I/O 속도 차이에 따른 성능저하를 최대한 막았다. 이러한 방식으로 Cache라는 별도의 하드웨어를 이용하여 I/O 속도차이에 따른 성능저하를 완화 시킬 수도 있고 DRAM 일부 공간에 disk데이터를 미리 올려둔다면 Cache와 같은 기능을 수행할 수 있을 것이다. 이러한 역할을 담당하는 것이 File System이다.

Q. 네트워크 시스템은 왜 I/O 시스템과 별도로 뒀을까?

A. Modern OS(unix, linux 등)는 I/O장치를 크게 3가지로 나눈다.

  1. Character I/O device: 입출력될때 그 단위가 byte인 장치(예: 키보드,마우스)
  2. Block I/O device: 입출력 단위가 block인 장치(예: 하드디스크)
    • block이란 과거엔 256byte였다면 요즘은 1K? 4K? 점점 늘어나고 있다. 컴퓨터시스템의 메모리에는 하드디스크, 메인메모리, 캐시, 레지스터 등이 있다. 하드디스크에서 파일 가지고 오는건 굉장히 오래걸린다. 그래서 디스크 전용 캐시를 하드웨어가 아니라 소프트웨어적으로 구현해놓으면 이건 Block I/O에 존재하며 사용자측면 성능이 확 오른다. 이걸 모아놓은게 File system.
  3. Network I/O device: network을 제어하는 장치 (예: 소켓)
    • 컴퓨터 시스템에서 출발해서 데이터를 보내려고 하면 ‘Queue’에 들어가야한다. 이 Queue 안에 중요하진 않은데 양이 엄청 많은 데이터패킷이 들어있으면, 중요한 패킷이 묻혀서 빨리 갈 수가 없다. 특히 continuous media같은걸 streaming할때 통신지연이 발생할 수 있다. 이때 속도에 민감한 패킷들은 별도의 Queue를 두고 보내줘야지 해결된다.

네트워크는 점점 패킷스케쥴링을 어떻게 하느냐에 따라 사람이 느끼는 성능이 달라진다. OS가 이런걸 신경써줘야한다. 그래서 character, block과는 별도의 시스템으로 만들어준거다.

2. Illusion Generator

OS는 추상화를 제공해야한다. OS를 사용하는 여러 유저들이 쉽게 프로그래밍을 할 수 있도록 해야한다. OS는 abstraction layer를 제공해서 사용자가 하드웨어의 복잡한 칩셋연산을 굳이 알지 않아도 컴퓨터 시스템을 사용할 수 있도록 해준다.

OS는 하나의 유저뿐만 아니라 여러 유저에게 동일한 abstraction을 제공해준다 이게 언제나 좋은 건 아니다. 잘못 구현되거나 정책이 잘못됐을때 시스템이 완전 나뻐지게 된다. 이걸 Thrashing이라고 한다.

Time sharing이라는건 OS가 제공하는 추상화기능의 하나이다. 컴퓨터 하나밖에 없지만 여러 유저가 individual computer를 부여받은듯한 느낌 illusion 을 준다. 이 time sharing기능이 어느 threshold를 넘으면 collapse하게 된다.

Time-sharing 시스템에서의 thrashing
사용자 수가 어떤 임계점을 넘어서는 순간 응답시간이 급격히 증가하는 현상

컴퓨터의 OS는 국가의 정부역할과 비슷하다 국민들은 task(process)로 볼 수 있다.

3. Standard Library

예를들어 키보드입력을 받아들이는 프로그램을 짜야된다면, OS가 갖고 있는 키보드 드라이버를 활용하면 된다. 이와 같이 시스템을 관리하기 위한 코드들(모듈들)을 제공해서 프로그래밍을 쉽게하도록 한다.

마무리

초기에는 하드웨어의 진화했다면 요즘은 하드웨어 진화보다는 사용자의 사용감, 시장의 요구를 만족하는 쪽으로 OS가 진화하고 있다.

Batch monitor -> intractive time sharing system -> connected systems

업데이트:

댓글남기기