File Systems

File and File System

  • File
    • A named collection of related information
    • 일반적으로 비휘발성의 보조기억장치에 저장
    • 운영체제는 다양한 저장 장치를 file이라는 동일한 논리적 단위로 보여줌
    • Operation
      • create, read, write, delete, open, close 등
  • Metadata
    • 파일 자체의 내용이 아니라 파일을 관리하기 위한 각종 정보
    • ex) 파일 이름, 유형, 저장 위치, 파일 크기
    • ex) 접근 권한, 시간(생성/변경/사용), 소유자 등
  • File System
    • 운영체제에서 파일을 관리하는 부분
    • 파일 및 파일의 Metadata, 디렉토리 정보 등 관리
    • 파일의 저장 방법 결정
    • 파일 보호 등

Directory and Logical Disk

  • Directory
    • 파일의 Metadata 중 일부를 보관하고 있는 특별한 파일
    • 디렉토리에 속한 파일 이름 및 파일의 metadata 등 보관
    • Operation
      • search for a file, create a file, delete a file
      • list a directory, rename a file, traverse the file system
  • Partition(=Logical Disk)
    • 하나의 디스크 안에 여러 Partition을 두는게 일반적
    • 여러 개의 물리적 디스크를 하나의 Partition으로 구성하기도 함
    • 디스크를 Partition으로 구성한 뒤 각각의 Partition에 file system을 깔거다 swapping 등 다른 용도로 사용 가능

open()

  • File의 Metadata를 메인 메모리에 올리는 행위
  • Directory path search 하는 데 너무 많은 시간 소요
    • read/write와 open을 따로 두는 이유!
  • 운영체제에서 파일을 복사한 후, 전달하는 것이 Buffer Cache
    • 운영체제가 cache한 정보를 다 가지고 있으므로 LRU, LFU 등의 알고리즘 사용 가능

File Protection

  • 각 파일에 대해 누구에게 어떤 유형의 접근을 허락할 것인가?
  • Access Control 방법

  • Access control Matrix는 모든 사용자에 대한 접근 권한 항목을 만들어야 하기 때문에 메모리 낭비가 큼
    • 주체에 따라 Linked List를 이용해 만드는 방법을 생각해볼 수 있음
    • 그러나, 이 역시 Overhead가 큼
  • 일반적으로 Grouping 기법 사용

File System의 Mounting






Access Methods

  • 순차 접근(sequential access)
    • 카세트 테이프를 사용하는 방식처럼 접근
    • 읽거나 쓰면 offset은 자동으로 증가
  • 직접 접근(direct access, random access)
    • LP 레코드 판과 같이 접근
    • 파일을 구성하는 레코드를 임의의 순서로 접근할 수 있음

Allocation of File Data in Disk

Contiguous Allocation

  • 하나의 파일이 Disk 상에 연속해서 저장되도록 하는 것
  • 장점
    • Fast I/O
      • 한 번의 seek / roation으로 많은 Byte transfer
      • Realtime file용으로, 또는 이미 run 중이던 프로세스의 swapping용
    • Direct access(=random access) 가능
  • 단점
    • External Fragmentation
    • File grow가 어려움
      • File 생성 시 얼마나 큰 hole을 배당할 것인가?
      • grow 가능케 넉넉히 배당할 수도 있지만, grow 하지 않는다면 그 공간은 낭비(Internal Fragmentation)

Linked Allocation

  • 장점
    • External Fragmentation 발생 안 함
  • 단점
    • No random access
    • Reliability 문제
      • 한 sector가 고장나 Pointer가 유실되면 많은 부분을 잃게 됨
    • Pointer를 위한 공간이 block의 일부가 되어 공간 효율성을 떨어뜨림
  • 변형
    • File-Allocation Table(FAT) 파일 시스템
    • 포인터를 별도의 위치에 보관하고 reliability와 공간 효율성 문제 해결

Indexed Allocation

  • Indexed 블럭에 파일의 위치를 저장하여 보여줌
  • 장점
    • External Fragmentation 발생하지 않음
    • Direct access 가능
  • 단점
    • Small file의 경우 공간 낭비
      • 실제로 많은 파일들이 small
    • Large File의 경우 하나의 block으로 index를 저장하기에 부족
      • 해결 방안
      • Linked Scheme: 또 다른 indexed block을 찾아가게 함
      • Multi-level index: like Two-level page

UNIX File System의 구조

  • Boot block
    • 부팅에 필요한 정보 저장(Bootstrap Loader)
  • Super block
    • 파일 시스템에 관한 총체적 정보를 담고 있음
  • Inode list
    • 파일 이름을 제외한 파일의 모든 Metadata 저장
    • 디렉토리는 특정 파일의 Metadata만 가지고 있지만, Inode list는 모든 파일의 Metadata를 가지고 있음
  • Data block
    • 파일의 실제 내용 보관
  • Indexed allocation을 사용하는 UNIX File System
    • 파일 크기에 따라 direct blocks만 사용할지,
    • single, double, triple indirect를 사용할지 결정
    • 한정된 크기의 inode로 모든 크기의 파일 관리 가능

FAT File System

  • 파일의 Metadata 중 일부(ex.위치 정보)를 FAT에 저장
    • 블럭의 다음 블럭을 저장하는 형식
    • 이미 Memory에 올라와 있는 FAT만 보면 되기 때문에, Direct access 가능해짐
    • 포인터 하나가 유실되더라도 FAT에 정보가 있기 때문에 Reliability 문제 해결
  • 나머지 Metadata는 Data block이 가지고 있음
  • FAT은 중요한 정보이기 때문에 보통 Disk에 2 copy 이상 저장

Free-Space Management

Bit map or bit vector

  • Bit map은 부가적 공간을 필요로 함
  • 연속적인 n개의 free block을 찾는데 효과적
    • bit map scan을 통해

Linked List

  • 모든 Free block들을 링크로 연결
  • 부가적 공간 낭비가 없음
  • 연속적 가용공간을 찾는 것이 쉽지 않음

Grouping

  • Linked list 방법의 변형
  • 첫 번째 Free block이 n개의 pointer를 가짐
    • n-1 Pointer는 free data block을 가리킴
    • 마지막 Pointer가 가리키는 block은 또 다시 n pointer를 가짐

Counting

  • 프로그램들이 종종 여러 개의 연속적인 block을 할당하고 반납한다는 성질에서 착안
  • (First free block, num of contiguous free block)을 유지

Directory Implementation

  • Linear List
    • <file name, file의 metadata>의 list
    • 구현이 간단
    • 디렉토리 내에 파일이 있는지 찾기 위해서는 Linear search가 필요
  • Hash Table
    • Linear list + hashing
    • Hash Table은 File name을 이 파일의 linear list의 위치로 바꾸어줌
    • Search time을 없애나, Collision 발생 가능
  • File metadata의 보관 위치
    • 디렉토리 내에 직접 보관하거나,
    • 디렉토리에는 포인터를 두고 다른 곳(ex. FAT, inode)에 보관
  • Long file name의 지원
    • <file name, file의 metadata>의 list에서 각 entry는 일반적으로 고정 크기
    • file name이 고정 크기의 entry 길이보다 길어지는 경우, entry의 마지막 부분에 이름의 뒷부분이 위치한 곳의 포인터를 두는 방법
    • 이름의 나머지 부분은 동일한 directory file의 일부에 존재

VFS and NFS

  • Virtual File System(VFS)
    • 서로 다른 다양한 file system에 대해 동일한 System call interface(API)를 통해 접근할 수 있게 해주는 운영체제의 layer
  • Network File System(NFS)
    • 분산 시스템에서는 네트워크를 통해 파일이 공유될 수 있음
    • NFS는 분산 환경에서의 대표적 파일 공유 방법

Page Cache and Buffer Cache

  • Page Cache
    • Virtual memory의 paging system에서 사용하는 page frame을 caching의 관점에서 설명하는 용어
    • Memory-Mapped I/O를 쓰는 경우 File의 I/O에서도 page cache 사용
  • Memory-Mapped I/O
    • File의 일부를 Virtual Memory에 Mapping 시킴
    • Mapping 시킨 영역에 대한 메모리 접근 연산은 파일의 입출력을 수행하게 함
    • 이미 메모리에 올라온 File은 마치 내 File 처럼 사용할 수 있는 장점!

  • Buffer Cache
    • 파일 시스템을 통한 I/O 연산은 메모리의 특정 영역인 Buffer cache 사용
    • File 사용의 locality 활용
      • 한 번 읽어온 block에 대한 후속 요청 시, buffer cache에서 즉시 전달
    • 모든 프로세스가 공용으로 사용
    • Replacement Algorithm 필요
  • Unified Buffer Cache
    • 최근 운영체제에서는 기존의 Buffer cache가 Page cache에 통합
    • 따라서 File block들도 Page 크기 단위(4KB)로 읽어옴


'Software Convergence > OS, Linux ' 카테고리의 다른 글

9. Virtual Memory  (0) 2018.09.26
8. Memory Management  (0) 2018.09.26
7. Deadlocks  (0) 2018.09.25
6. Process Synchronization (2)  (0) 2018.09.25
6. Process Synchronization (1)  (0) 2018.09.20

Virtual Memory

Demand Paging

  • 실제로 필요할 때 Page를 메모리에 올리는 것
    • I/O 양의 감소
    • Memory 사용량 감소
    • 빠른 응답 시간
    • 더 많은 사용자 수용
  • Valid / Invalid bit의 사용
    • Invalid의 의미
      • 사용되지 않는 주소 영역인 경우
      • Page가 물리적 메모리에 없는 경우
    • 처음에는 모든 Page entry가 invalid로 초기화
    • address translation시에 invalid bit이 set 되어 있으면, Page fault

Page Fault

  • invalid page를 접근하면 MMU가 Page Fault Trap을 발생시킴
  • Kernel mode로 들어가 Page fault handler를 invoke
  • 다음 순서로 Page Fault 처리
    • Invalid reference? -> abort process
    • Get an empty page frame (없으면 replace)
    • 해당 Page를 disk에서 memory로 읽어옴
      • disk I/O가 끝나기까지 이 프로세스는 block
      • Disk read가 끝나면 Page table entry 기록 후, valid bit set
      • Ready queue에 process 삽입
    • 이 프로세스가 CPU 잡고 다시 running
    • 아까 중단되었던 intruction 재개

free frame이 없는 경우

  • Page replacement
    • 어떤 frame을 뺴앗아올지 결정해야 함
    • 곧바로 사용되지 않을 Page 쫓아내는 것이 좋음
    • 동일 Page가 여러 번 메모리에서 쫓겨났다가 다시 들어올 수 있음
  • Replacement Algorithm
    • Page-fault rate을 최소화하는 것이 목표
    • 주어진 Page reference string에 대해 Page fault를 얼마나 내는지 조사하여 평가 가능

Optimal Algorithm

  • 가장 먼 미래에 참조되는 Page를 replace
  • 현실적으로 불가능하기 때문에 다른 알고리즘의 성능에 대한 Upper bound 제공

FIFO Algorithm

  • FIFO Anomaly: frame 수를 올렸음에도, Page fault의 수가 늘어날 수 있음

LRU Algorithm

  • 가장 오래 전에 참조된 Page를 replace

LFU Algorithm

  • 최저 참조 횟수의 Page를 replace
  • 최저 참조 횟수 page가 여러 개인 경우?
    • 여러 Page 중 임의로 선정하거나,
    • 성능 향상을 위해 가장 오래 전에 참조된 Page를 replace
  • 장단점
    • LRU처럼 직접 참조 시점만 보는 것이 아리나 장기적 시간 규모를 보기 때문에 Page의 인기도를 더 정확히 반영할 수 있음
    • 참조 시점의 최근성을 반영하지 못함
    • LRU 보다 구현이 복잡함
  • LRU vs. LFU

LRU와 LFU 알고리즘의 구현


다양한 캐싱 환경

  • 캐싱 기법
    • 한정된 빠른 공간(캐시)에 요청된 데이터를 저장해두었다가 후속 요청 시 캐시로부터 직접 서비스하는 방식
    • Paging System 외에도 Cache memory, buffer caching, web caching 등 다양한 분야에서 사용
  • 캐시 운영의 시간 제약
    • 교체 알고리즘에서 삭제할 항목을 결정하는 일에 지나치게 많은 시간이 걸리는 경우 실제 시스템에서 사용할 수 없음
    • Buffer caching이나 Web caching의 경우
      • O(1)에서 O(log N) 정도까지 허용
    • Paging System의 경우
      • Page fault의 경우에만 운영체제가 관여
        • Page가 이미 메모리에 존재하는 경우 참조 시간 등의 정보를 운영체제가 알 수 없음
        • LRU의 list 조작 조차 불가능

Clock Algorithm

  • LRU의 근사 알고리즘
  • a.k.a Second chance algorithm, NRU(Not Recently Used)
  • Referece bit를 사용해서 교체 대상 페이지 선정
    • Reference bit가 0인 것을 찾을 때 까지 포인터를 하나씩 앞으로 이동
  • 포인터가 이동하는 중에 Reference bit 1은 모두 0으로 set
  • Reference bit이 0인 것을 찾으면 해당 Page 교체
  • 한 바퀴 되돌아와서도(=Second chance) 0이면 그 때 replace
    • 자주 사용되는 Page라면 Second chance 올 때 1
  • Clock Algorithm의 개선
    • reference bit와 modified bit를 함께 사용
    • reference bit = 1; 최근에 참조된 Page
    • modified bit = 1; 최근에 변경된 Page(I/O 동반하는 page)
    • 가능한 modified bit이 0인 Page를 쫓아내서 시간 단축할 수 있을 것

Page Frame의 Allocation

  • Allocation problem: 각 프로세스에 얼마만큼의 Page frame을 할당할 것인가?
  • Allocation의 필요성
    • 메모리 참조 명령어 수행 시 명령어, 데이터 등 여러 Page 동시 참조
      • 명령어 수행을 위해 최소 할당되어야 하는 frame 수가 존재
    • Loop를 구성하는 Page들은 한꺼번에 allocate되는 것이 유리함
      • 최소한의 allocation이 없으면 매 loop 마다 page fault
  • Allocation Sheme
    • Equal allocation: 모든 프로세스에 똑같은 개수 할당
    • Proportinal allocation: 프로세스 크기에 비례하여 할당
    • Priority allocation: 프로세스의 priority에 따라 다르게 할당

Global vs. Local Replacement

  • Global replacement
    • Replace 시 다른 프로세스에 할당된 frame을 뺏을 수 있음
    • 프로세스 별 할당량을 조절하는 또 다른 방법
    • FIFO, LRU, LFU 등의 알고리즘을 global replacement로 사용 시에 해당
    • Working set, PFF 알고리즘 사용
  • Local replacement
    • 자신에게 할당된 frame 내에서만 replacement
    • FIFO, LRU, LFU 등의 알고리즘을 프로세스 별로 운영

Thrashing

  • 프로세스의 원활한 수행에 필요한 최소한의 Page frame 수를 할당 받지 못한 경우 발생
  • Page fault rate가 매우 높아짐
  • CPU utilization이 낮아짐
  • 운영체제는 Multiprogramming degree를 높여야 한다고 판단
  • 또 다른 프로세스가 시스템에 추가됨
  • 프로세스 당 할당된 frame의 수가 더욱 감소
  • 프로세스는 page의 swap in / swap out으로 매우 바쁨
  • CPU가 idle 해지는 현상 발생
  • Low throughput

Working-set Model

  • Locality of reference
    • 프로세스는 특정 시간 동안 일정 장소만을 집중적으로 참조
    • 집중적으로 참조되는 해당 Page들의 집합을 Locality set이라 함
  • Working-set Model
    • Locality에 기반하여 프로세스가 일정 시간 동안 원활하게 수행되기 위해 한 번에 메모리에 올라와 있어야 하는 Page들의 집합을 Working Set이라 정의
    • Working Set 모델에서는 프로세스의 Working Set 전체가 메모리에 올라와있어야 수행되고 그렇지 않을 경우 모든 frame을 반납한 후 Swap out
    • Thrashing을 방지!
    • Multiprogramming degree를 결정

  • Working set의 결정
    • Working set window를 통해 알아냄
    • window size가 delta인 경우,
      • Working set에 속한 Page는 메모리에 유지, 속하지 않은 것은 버림
      • 즉, 참조된 후 delta 시간 동안 해당 page를 메모리에 유지한 후 버림
    • 시간 별로 Working set의 크기는 유동적으로 변함
  • Window size delta
    • Working set을 제대로 탐지하기 위해서는 Window size를 잘 결정해야 함
    • delta 값이 너무 작으면 locality set 모두 수용하지 못할 우려
    • delta 값이 너무 크면 여러 규모의 locality set 수용
  • Working-set Algorithm
    • 프로세스들의 working set size의 합이 page frame 보다 큰 경우
      • 일부 프로세스를 swap out 시켜 남은 프로세스의 working set을 우선적으로 충족시킴
    • Working set을 다 할당하고도 Page frame이 남는 경우
      • Swap out 되었던 프로세스에게 Working set 할당

PFF(Page Fault Frequency) Model

  • Page fault rate의 상한값과 하한값을 설정
    • Page fault rate이 상한값을 넘으면 frame을 더 할당
    • Page fault rate이 하한값 이하이면 할당 frame 수를 줄임
  • 빈 frame이 없으면 일부 프로세스를 Swap out

Page Size의 결정

  • Page size를 감소시키면
    • Page 수 증가
    • Page table 크기 증가
    • Internal fragmentation 감소
    • Disk Transfer의 효율성 감소
      • Seek/Rotation vs. Transfer
    • 필요한 정보만 메모리에 올라와 메모리 이용이 효율적
      • Locality의 활용 측면에서는 좋지 않음
  • 트렌드는 Larger page size


'Software Convergence > OS, Linux ' 카테고리의 다른 글

10. File Systems  (0) 2018.09.26
8. Memory Management  (0) 2018.09.26
7. Deadlocks  (0) 2018.09.25
6. Process Synchronization (2)  (0) 2018.09.25
6. Process Synchronization (1)  (0) 2018.09.20

Memory Management

Logical vs. Physical Address

  • Logical address(=Virtual address)
    • 프로세스마다 독립적으로 가지는 주소 공간
    • 각 프로세스마다 0번지부터 시작
    • CPU가 보는 주소는 Logical address
  • Physical address
    • 메모리에 실제 올라가는 위치
  • 주소 바인딩: 주소를 결정 하는 것
    • Symbolic addr -> Logical addr -> Physical addr
    • cf. Symbolic addr: 프로그래머 입장에서의 주소(변수, 함수 등)

Address Binding

  • Compile time binding
    • 물리적 메모리 주소가 컴파일 시 알려짐
    • 시작 위치 변경 시 재컴파일
    • 컴파일러는 절대 코드(absolute code) 생성
    • 컴파일 시 항상 논리적이자 물리적 주소를 알아야 하므로 비효율적(현대에는 사용 x)
  • Load time binding
    • Loader의 책임 하에 물리적 메모리 주소 부여
    • 컴파일러가 재배치 가능 코드(relocatable code)를 생성한 경우 사용 가능
  • Execution time binding(=Run time binding)
    • 수행이 시작된 이후에도 프로세스의 메모리 상 위치를 옮길 수 있음
    • CPU가 주소를 참조할 때 마다 binding을 점검
    • 하드웨어적 지원이 필요(MMU)
    • 대부분의 현대 컴퓨터에서 지원

Memory Management Unit (MMU)

  • Logical Addr를 Physical Addr로 매핑해주는 하드웨어 장치

  • MMU scheme
    • 사용자 프로세스가 CPU에서 수행되며 생성해내는 모든 주소값에 대해 base register(=relocation register)의 값을 더함
  • User program
    • Logical addr만을 다룸
    • 실제 Physical addr를 볼 수 없으며 알 필요도 없음
  • Relocation register는 접근할 수 있는 물리적 메모리의 최소값(프로그램의 시작점)
  • Limit register는 악성 프로그램이 요청 프로그램의 크기를 벗어나는 주소 번지를 요청하는 경우를 방지하기 위해 사용

Dynamic Loading

  • 프로세스 전체를 메모리에 미리 다 올리는 것이 아니라 해당 루틴이 불려질 때 메모리에 Load하는 것
    • Memory utilization의 향상
  • 가끔씩 사용되는 많은 양의 코드의 경우 유용
    • ex) 오류 처리 루틴
  • 운영체제의 특별한 지원 없이 프로그램 자체에서(Library를 통해) 구현 가능
  • Paging 기법과는 다른 기법

Overlays

  • 메모리에 프로세스의 실제 필요한 정보만을 올림
  • 프로세스의 크기가 메모리보다 클 때 유용
  • 운영체제의 지원 없이 사용자에 의해 구현
  • 작은 공간의 메모리를 사용하던 초창기 시스템에서 수 작업으로 프로그래머가 구현
    • Manual Overlay -> 프로그래밍이 매우 복잡

Swapping

  • 프로세스 전체를 일시적으로 메모리에서 backing store로 쫓아내는 것
  • Backing Store(=Swap area)
    • 디스크: 많은 사용자의 프로세스 이미지를 담을 만큼 충분히 빠르고 큰 저장 공간
  • Swap in / Swap out
    • 일반적으로 중기 스케줄러(Swapper)에의해 Swap out 시킬 프로세스 선정
    • Priority-based CPU scheduling algorithm
      • 우선순위 높은 프로세스를 메모리에 올려 놓음
      • 우선순위 낮은 프로세스를 Swap out
    • Compile time 혹은 Load time binding에서는 원래 동작하던 메모리 위치로 Swap in 해야 함 (비효율)
    • Execution time binding에서는 추후 빈 메모리 영역 아무 곳에나 올릴 수 있음 (효율)

Dynamic Linking

  • Linking을 실행 시간까지 미루는 기법
  • Static Linking
    • 라이브러리가 프로그램의 실행 파일 코드에 포함
    • 실행 파일의 크기가 커짐
    • 동일한 라이브러리를 각각의 프로세스가 메모리에 올리므로 메모리 낭비
  • Dynamic Linking
    • 라이브러리가 실행 시 Link됨
    • 라이브러리 호출 부분에 라이브러리 루틴의 위치를 찾기 위한 stub이라는 작은 코드를 둠
    • 라이브러리가 이미 메모리에 있으면 그 루틴의 주소로 가고 없으면 디스크에서 읽어옴
    • 운영체제의 도움이 필요

Allocation of Physical Memory

  • 메모리는 일반적으로 두 영역으로 나누어 사용
    1. OS 상주 영역: interrupt vector와 함께 낮은 주소 영역 사용
    2. 사용자 프로세스 영역: 높은 주소 영역 사용
  • 사용자 프로세스 영역의 할당 방법
    • Contiguous allocation
      • 각각의 프로세스가 메모리의 연속적 공간에 적재되도록 하는 것
      • Fixed partition allocation / Variable partition allocation
    • Non-contiguous allocation (현대에 사용)
      • 하나의 프롯스가 메모리의 여러 영역에 분산되어 올라갈 수 있음
      • Paging / Segmentation / Paged Segmentation

Contiguous Allocation

Fixed Partition

  • 물리적 메모리를 몇 개의 영구적 분할로 나눔
  • 분할의 크기가 모두 동일한 방식과 서로 다른 방식이 존재
  • 분할 당 하나의 프로그램 적재
  • 융통성이 없음
    • 동시에 메모리에 Load되는 프로그램의 수가 고정
    • 최대 수행 가능 프로그램 크기 제한
  • Internal / External Fragmentation 발생

Variable Partition

  • 프로그램의 크기를 고려해서 할당
  • 분할의 크기, 개수가 동적으로 변함
  • 기술적 관리 기법 필요
  • External Fragmentation 발생

Internal Fragmentation
  • 프로그램 크기보다 분할의 크기가 큰 경우 발생
  • 하나의 분할 내부에서 발생하는, 사용되지 않는 메모리 조각
  • 특정 프로그램에 배정되었지만 사용되지 않는 공간

External Fragmentation
  • 프로그램 크기보다 분할의 크기가 작은 경우
  • 아무 프로그램에도 배정되지 않은 빈 공간인데도 프로그램이 올라갈 수 없는 작은 분할

Hole

  • 가용 메모리 공간
  • 다양한 크기의 hole들이 메모리 여러 곳에 산재
  • 프로세스가 도착하면 수용 가능한 hole 할당
  • 운영체제는 할당 공간 / 가용 공간의 정보를 유지

Dynamic Allocation Problem

  • First-fit
    • Size가 n 이상인 것 중 최초로 찾아지는 hole에 할당
  • Best-fit
    • Size가 n 이상인 가장 작은 hole 찾아 할당
    • hole들의 리스트가 크기 순으로 정렬되지 않은 경우 모든 hole의 리스트를 탐색해야 함
    • 많은 수의 아주 작은 hole들이 생성됨
  • Worst-fit
    • 가장 큰 hole에 할당
    • 역시 모든 리스트를 탐색해야 함
    • 상대적으로 아주 큰 hole들이 생성
  • First-fit과 Best-fit이 속도와 공간 이용률 측면에서 효과적으로 알려짐

Compaction

  • External fragmentation 문제를 해결하는 방법
  • 사용 중인 메모리 영역을 한 군데로 몰고 hole들을 다른 한 곳으로 모아 큰 block을 만드는 것
  • 매우 비용이 많이 드는 방법
  • Compaction은 프로세스의 주소가 실행 시간에 동적으로 재배치 가능한 경우에만 사용 가능

Non-contiguous Allocation

Paging

  • Paging
    • 프로세스의 Virtual memory를 동일한 사이즈의 page 단위로 나눔
    • Virtual memory의 내용이 page 단위로 non-contiguous 하게 저장됨
    • 일부는 backing storage에, 일부는 physical memory에 저장
  • Basic method
    • Physical memory를 동일한 크기의 Frame으로 나눔
    • Logical memory를 동일한 크기의 Page로 나눔(frame과 같은 크기)
    • 모든 가용 frame들을 관리
    • Page table을 사용하여 Logical addr를 Physical addr로 변환
      • 프로그램마다 Page table 존재
    • External fragmentation 발생 X
    • Internal fragmentation 발생 O

Implementation of Page Table

  • Page Table은 main memory에 상주
  • 모든 메모리 접근 연산에는 2번의 메모리 접근이 필요
    • Page table 1번 + 실제 data/instruction 1번
  • 속도 향상을 위해 associative register 혹은 Translation Look-aside Buffer(TLB)라 불리는 고속의 Lookup Hardware Cache 사용

  • TLB Search에도 시간이 오래 걸리므로, Parallel search를 지원
  • TLB는 context switch 때 Flush 됨 (TLB도 프로세스에 따라 다르기 때문)

Two-Level Page Table

  • 현대 컴퓨터는 address space가 매우 큰 프로그램 지원
    • 그러나 대부분의 프로그램은 주소 공간 중 지극히 일부분만 사용하므로 page table 공간이 심하게 낭비
    • Page table 자체를 page로 구성하자!
    • 사용되지 않는 주소 공간에 대한 Outer page table의 entry 값은 NULL -> 메모리 save 가능
  • Multi-level Paging and Performance
    • 주소 공간이 더 커지면 다단계 Page table 필요
    • 각 단계의 Page table이 메모리에 존재하므로 Logical addr의 Physical addr 변환에 더 많은 메모리 접근 필요
    • TLB 통해 메모리 접근 시간 줄일 수 있음 -> Overhead 크지 않음!

Memory Protection

  • Page Table의 각 entry 마다 아래의 bit를 둠
    • Protection bit
      • page에 대한 접근 권한(read/write/readonly)
    • Valid-Invalid bit
      • valid는 해당 주소의 frame에 그 프로세스를 구성하는 유효한 내용이 있음을 의미(접근 허용)
      • invalid는 해당 주소의 frame에 유효한 내용이 없음을 의미(접근 불허)
        • 프로세스가 그 주소 부분을 사용하지 않는 경우
        • 해당 페이지가 메모리에 올라와 있지 않고, swap area에 있는 경우

Inverted Page Table

  • Page frame 하나 당 page table에 하나의 entry를 두는 것
  • 각 page table entry는 각각의 물리적 메모리의 page frame이 담고 있는 내용 표시
  • 장점: Page table entry 사용공간을 줄일 수 있음
  • 단점: 테이블 전체를 탐색해야 위치를 알 수 있음
  • 조치: TLB 사용 통해 Parallel search

Shared Page

  • Shared code
    • Re-entrant code(=Pure code)
    • readonly로 하여 프로세스 간에 하나의 code만 메모리에 올림
    • Shared code는 모든 프로세스의 Logical addr space에서 동일한 위치에 있어야 함
      • 주소 변환 통해 같은 Physical addr로 가야 하기 때문에
  • Private code and data
    • 각 프로세스들은 독자적으로 메모리에 올림
    • Private data는 Logical addr space의 아무 곳에 와도 무방

Segmentation

  • 프로그램을 의미 단위인 여러 개의 Segment로 분할
    • 작게는 프로그램을 구성하는 함수 하나 하나로,
    • 크게는 프로그램 전체를 하나의 segment로 정의 가능
  • 일반적으로는 code, data, stack 부분이 하나씩의 Segment로 정의됨
  • Segmentation은 Paging 기법보다 메모리 낭비가 적음
  • Segment의 길이가 균일하지 않을 수 있기 때문에, 주소 변환 시 길이를 의미하는 limit 변수를 함께 전달

Segmentation Architecture

  • Protection
    • 각 Segment 별로 Protection bit 존재
    • Each entry:
      • valid bit = 0 -> illegal segment
      • read/write/execution 권한 bit
  • Sharing
    • Shared segment
    • Same segment number
    • cf. Segment는 의미 단위이기 때문에 공유와 보안에 있어 paging보다 훨씬 효과적
  • Allocation
    • First fit / best fit
    • External fragmentation 발생
      • Segment의 길이가 동일하지 않으므로 가변분할 방식에서와 동일한 문제점들 발생

Paged Segmentation

  • Segment 하나가 여러 개의 page로 구성
  • 물리적 메모리에는 Page 단위로 올라감
    • Allocation 문제 발생 안 됨


'Software Convergence > OS, Linux ' 카테고리의 다른 글

10. File Systems  (0) 2018.09.26
9. Virtual Memory  (0) 2018.09.26
7. Deadlocks  (0) 2018.09.25
6. Process Synchronization (2)  (0) 2018.09.25
6. Process Synchronization (1)  (0) 2018.09.20

Deadlocks

The Deadlock Problem

  • Deadlock: 일련의 프로세스들이 서로가 가진 자원을 기다리며 Block된 상태
  • Resource
    • 하드웨어, 소프트웨어 등을 포함하는 개념
    • ex) I/O device, CPU Cycle, Memory space, Semaphore 등
    • 프로세스가 자원을 사용하는 절차
      • Request, Allocate, Use, Release
  • Deadlock example 1
    • 시스템에 2개의 Tape drive가 있음
    • 프로세스 P1과 P2 각각이 하나의 Tape drive를 보유한 채 다른 하나를 기다림
  • Deadlock example 2


Deadlock 발생의 4가지 조건

  • Mutual exclusion
    • 매 순간 하나의 프로세스만이 자원의 사용 가능
  • No preemption
    • 프로세스는 자원을 강제로 빼앗기지 않음
  • Hold and wait
    • 자원을 가진 프로세스가 다른 자원을 기다릴 때 보유 자원을 놓지 않고 계속 가지고 기다림
  • Circular wait
    • 자원을 기다리는 프로세스 간 사이클이 형성됨
    • 프로세스 P0, P1, ..., Pn이 있을 때
      • P0은 P1이 가진 자원을 기다림
      • P1은 P2가 가진 자원을 기다림
      • Pn-1은 Pn이 가진 자원을 기다림
      • Pn은 P0이 가진 자원을 기다림

Resource-Allocation Graph (자원 할당 그래프)

  • Deadlock 여부를 확인하기 위한 그래프


Deadlock의 처리 방법

  • Deadlock Prevention
    • 자원 할당 시 Deadlock의 4가지 필요 조건 중 어느 하나가 만족되지 않도록 하는 것
  • Deadlock Avoidance
    • 자원 요청에 대한 부가적 정보를 이용해서 Deadlock의 가능성이 없는 경우에만 자원 할당
    • 시스템 state가 원래 state로 돌아올 수 있는 경우에만 자원 할당
  • Deadlock Detection and recovery
    • Deadlock 발생은 허용하되 그에 대한 Detection 루틴을 두어 Deadlock 발견 시 Recovery
  • Deadlock Ignorance
    • Deadlock을 시스템이 책임지지 않음
    • UNIX를 비롯한 대부분의 OS가 채택

Deadlock Prevention

  • Mutual exclusion
    • 반드시 성립해야 하는 조건
  • Hold and wait
      1. 프로세스 시작 시 모든 필요한 자원을 할당 받게 하는 방법
      1. 자원이 필요할 경우 보유 자원을 모두 놓고 다시 요청
  • No preemption
    • 프로세스가 어떤 자원을 기다려야 하는 경우 이미 보유한 자원은 다른 프로세스에 의해 선점됨
    • 모든 필요한 자원을 얻을 수 있을 때 그 프로세스는 다시 시작
    • state를 쉽게 저장하고 복구할 수 있는 자원에서 주로 사용(CPU, memory)
  • Circular wait
    • 모든 자원 유형에 할당 순서 정하여 정해진 순서대로만 자원 할당
  • 생기지도 않을 Deadlock의 고려로 인해 비효율적 시스템 설계로 이어질 수 있음

Deadlock Avoidance

  • 자원 요청에 대한 부가정보를 이용해서 자원을 할당하는 것이 Deadlock으로부터 안전한지를 조사해서 안전한 경우에만 할당
  • 가장 단순하고 일반적 모델은 프로세스들이 필요로 하는 각 자원별 최대 사용량을 미리 선언하도록 하는 방법
  • Safe State
    • 시스템 내의 프로세스들에 대한 Safe Sequence가 존재하는 상태
  • Safe Sequence
    • 프로세스의 Sequence가 Safe하려면 Pi의 자원 요청이 가용 자원 + 모든 Pj(j < i)의 보유 자원에 의해 충족되어야 함
    • 조건을 만족하면 다음 방법으로 모든 프로세스의 수행을 보장
      • Pi의 자원 요청이 즉시 충족될수 없으면 모든 Pj가 종료될 때 까지 기다림
      • Pi-1이 종료되면 Pi의 자원요청을 만족시켜 수행


Resource Allocation Graph Algorithm
  • 점선은 프로세스가 평생에 한 번은 해당 자원을 사용할 수 있다는 것을 의미

Banker's Algorithm
  • 가정
    • 모든 프로세스는 자원의 최대 사용량을 미리 명시
    • 프로세스가 요청 자원을 모두 할당 받은 경우 제한된 시간 안에 이들 자원을 다시 반납
  • 방법
    • 기본 개념: 자원 요청 시 safe 상태를 유지할 경우에만 할당
    • 총 요청 자원의 수가 가용 자원의 수 보다 적은 프로세스를 선택 (해당 프로세스 없으면 unsafe 상태)
      • 그런 프로세스가 있으면 그 프로세스에게 자원 할당
    • 할당 받은 프로세스가 종료되면 모든 자원 반납
    • 모든 프로세스가 종료될 때 까지 이 과정 반복




Deadlock Detection and recovery

  • Deadlock Detection
    • Resource type 당 single instance인 경우
      • 자원 할당 그래프에서의 cycle이 곧 deadlock을 의미
    • Resource type 당 multiple instance인 경우
      • Banker's algorithm과 유사한 방법 활용
        • 사실 single instance인 경우에도 이 방법 활용하는 것이 더 효율적
      • 낙관적으로 Request가 없는 프로세스는 소유한 자원을 반납할 것이라고 가정
  • Wait-for graph Algorithm
    • Resource type 당 single instance인 경우
    • Wait-for graph

      • 자원 할당 그래프의 변형
      • 프로세스만으로 node 구성
      • Pj가 가지고 있는 자원을 Pk가 기다리는 경우 Pk -> Pj
      • Algorithm
        • Wait-for graph에 cycle이 존재하는지를 주기적으로 조사
        • O(n^2): n(n-1) 만큼의 화살표가 존재할 수 있기 때문
  • Recovery
    • Process termination
        1. Deadlock에 연루된 모든 프로세스 종료
        1. Deadlock cycle이 제거될 때 까지 한 번에 하나의 프로세스씩 종료
    • Resource Preemption
      • 비용을 최소화 할 Victim의 선정
      • Safe state로 Rollback하여 프로세스 재시작
      • Starvation 문제
        • 동일 프로세스가 계속해서 Victim으로 선정되는 경우
        • -> Cost factor에 Rollback 횟수도 같이 고려!

Deadlock Ignorance

  • Deadlock이 매우 드물게 발생하므로 deadlock에 대한 조치 자체가 더 큰 overhead일 수 있음
  • 만약 시스템에 deadlock이 발생한 경우 시스템이 비정상적으로 작동하는 것을 느낀 프로그래머가 직접 프로세스를 죽이는 등의 방법으로 대처


'Software Convergence > OS, Linux ' 카테고리의 다른 글

9. Virtual Memory  (0) 2018.09.26
8. Memory Management  (0) 2018.09.26
6. Process Synchronization (2)  (0) 2018.09.25
6. Process Synchronization (1)  (0) 2018.09.20
5. CPU Scheduling  (0) 2018.09.17

Process Synchronization (2)

Classical Problems of Synchronization

Bounded-Buffer Problem(Producer-Consumer Problem)

  • Shared data
    • buffer 자체 및 buffer 조작 변수
  • Synchronizaiton variables
    • mutual exclusion: Need binary semaphore(Shared data의 mutual exclusion을 위해)
    • resource count: Need integer semaphore(남은 full/empty buffer의 수 표시)

Readers-Writers Problem

  • 한 프로세스가 Database에 write 중일 때 다른 프로세스가 접근하면 안 됨
  • read는 동시에 여럿이 해도 됨
  • 해결책
    • Writer가 DB에 접근 허가를 아직 얻지 못한 상태에서는 모든 대기 중인 Reader들은 다 DB에 접근 가능케 해줌
    • Writer는 대기 중인 Reader가 하나도 없을 때 DB 접근이 허용
    • 일단 Writer가 DB에 접근 중이면 Reader들은 접근이 금지
    • Writer가 DB에서 빠져나가야만 Reader의 접근 허용
  • Shared data
    • Database 자체
    • int readcount; //(현재 DB에 접근 중인 Reader의 수)
  • Synchronization variables
    • mutex: 공유 변수 readcount를 접근하는 critical section의 mutual exclusion을 보장하기 위해 사용
    • db: Reader와 Writer가 공유 DB 자체를 올바르게 접근 하는 역할

  • 최초의 Reader는 readcount를 증가시켜주어, db에 lock을 걸어줌
  • readcount 자체도 공유 변수이기 때문에 Semaphore 사용하여, Lock/Unlock 처리를 해줌
  • readcount가 0이 되는 경우, db에 건 lock을 unlock 해주며 Reader 마무리
  • 너무 늦게 들어온 Reader보다 Writer가 우선순위 높게 하는 방식 등으로 Starvation 문제 해결 가능할 것

Dining Philosophers Problem

  • Problem
    • 모든 철학자가 동시에 왼쪽 젓가락을 집어버리면 Deadlock이 생김
  • Solution
    • 4명의 철학자만이 테이블이 동시에 앉을 수 있도록 함

    • 젓가락을 두 개 모두 집을 수 있을 때에만 젓가락을 집을 수 있게 함(좌/우측 철학자가 식사 중이 아닐 때, 내가 젓가락을 들 수 있음)
    • 비대칭
      • 짝수 철학자는 왼쪽 젓가락부터 잡음
      • 홀수 철학자는 오른쪽 젓가락부터 잡음

Monitor

  • Semaphore의 문제점
    • 코딩의 어려움
    • 정확성의 입증이 어려움
    • 자발적 협력이 필요
    • 한 번의 실수가 모든 시스템에 치명적 영향


  • Monitor: 동시 수행 중인 프로세스 사이에서 추상 데이터 타입의 안전한 공유를 보장하기 위한 high-level synchronization construct
    • Monitor 내부에 공유 데이터를 두고, 하나의 프로세스 씩 동작하게 하는 식으로 진행
    • 프로그래머가 동기화 제약 조건을 명시적으로 코딩 할 필요가 없음
    • 프로세스가 모니터 안에서 기다릴 수 있도록 condition variable 사용
    • Condition variable은 _wait_와 signal 연산에 의해서만 접근 가능
      • signal을 사용할 때 suspend 상태인 프로세스가 없는 경우, 아무 일도 일어나지 않음
  • Monitor를 이용한 Dining Philosophers 문제의 해결
    • 상대의 state를 변경할 수 있기에 공유 변수 처리


'Software Convergence > OS, Linux ' 카테고리의 다른 글

8. Memory Management  (0) 2018.09.26
7. Deadlocks  (0) 2018.09.25
6. Process Synchronization (1)  (0) 2018.09.20
5. CPU Scheduling  (0) 2018.09.17
4. Process Management  (0) 2018.09.16

Process Synchronization (1)

데이터의 접근

  1. 데이터가 스토리지에 저장
  2. 연산할 데이터를 fetch
  3. 데이터 연산
  4. 연산 결과 스토리지에 저장

Race Condition

  • 스토리지가 공유되어 여러 연산이 동시에 실행될 경우, Race Condition의 가능성이 있음
  • CPU / Memory, Process / Address space와의 관계에서 생기는 문제
  • 커널 내부 데이터를 접근하는 루틴들 간에도 문제가 있을 수 있음
    • ex) 커널 모드 수행 중 인터럽트로 커널 모드 다른 루틴 수행 시

OS에서 Race Condition은 언제 발생하는가?

  • kernel mode 수행 중 interrupt 발생 시
    • 커널 모드 running 중 interrupt가 발생하여 interrupt 처리 루틴이 수행
    • 양 쪽 다 커널 코드이므로, kernel address space 공유
    • disable / enable interrupt로 문제 해결 가능
  • Process가 System call을 하여 kernel mode로 수행 중인데, context switch가 일어나는 경우
    • 두 프로세스의 address space 간에는 data sharing이 없음
    • 그러나 system call을 하는 동안에는 kernel address space의 data에 접근하게 됨
    • 이 작업 중간에 CPU를 선점해가면 Race condition 발생
    • 커널 모드에서 수행 중일때는 CPU를 선점하지 않고, 사용자 모드로 돌아갈 때 선점하는 것으로 해결 가능
  • 멀티프로세서에서 shared memory 내의 kernel data
    • 어떤 CPU가 마지막으로 count를 store 했는가에 대한 Race condition 발생
    • 해결책1: 한 번에 하나의 CPU만이 커널에 들어갈 수 있게 함(비효율)
    • 해결책2: 커널 내부에 있는 각 공유 데이터에 접근할 때 마다 그 데이터에 대한 lock / unlock을 함

Process Synchronization 문제

  • 공유 데이터의 동시 접근은 데이터의 불일치 문제를 발생시킬 수 있음
  • 일관성 유지를 위해서는 협력 프로세스 간의 실행 순서를 정해주는 메커니즘이 필요
  • Race Condition
    • 여러 프로세스들이 동시에 공유 데이터를 접근하는 상황
    • 데이터의 최종 연산 결과는 마지막에 그 데이터를 다룬 프로세스에 따라 달라짐
  • Race condition을 막기 위해서는 concurrent process는 동기화되어야 함

The Critical-Section Problem

  • n개의 프로세스가 공유 데이터를 동시에 사용하기를 원하는 경우
  • 각 프로세스의 code segment에는 공유 데이터를 접근하는 코드인 critical section이 존재
  • 문제: 하나의 프로세스가 critical section에 있을 때 다른 모든 프로세스는 critical section에 들어가지 않아야 함

프로그램적 해결법의 충족 조건

  • Mutual Exclusion
    • 프로세스가 critical section 부분을 수행 중이면 다른 모든 프로세스들은 그들의 critical section에 들어가면 안 됨
  • Progress
    • 아무도 critical section에 있지 않은 상태에서 critical section에 들어가고자 하는 프로세스가 있으면 critical section에 들어가게 해주어야 함
  • Bounded Waiting
    • 프로세스가 critical section에 들어가려고 요청한 그 후부터 그 요청이 허용될 때 까지 다른 프로세스들이 critical section에 들어가는 횟수에는 한계가 있어야 함

Initial Attempts to solve problem

  • 프로세스들의 일반적 구조
  • 프로세스들은 수행의 동기화를 위해 몇몇 변수를 공유할 수 있음 -> synchronization variable

Algorithm 1

  • Synchronization variable
    • int turn;
    • initially turn = 0
      • Pi can enter its critical section if (turn == i)
  • Process Pi

  • Mutual Exclusion은 만족하지만 Progress 불만족
    • 반드시 한 번씩 교대로 들어가야 하기 때문에 critical section에 들어가 있는 프로세스가 turn 값을 바꾸어줘야 Progress가 생기기 때문
    • P1은 critical section에 1번 들어가고, P0은 지속적으로 들어가야 하는 상황이라면 P1이 turn을 반납하지 않아 아무도 critical section을 이용하지 못하게 될 가능성 존재

Algorithm 2

  • Synchronization variable
    • boolean flag[2];
    • initially flag[모두] = false; //no one is in critical section
    • Pi ready to enter its critical section if (flag[i] == true)
  • Process Pi

  • Mutual Exclusion은 만족하지만 Progress 불만족
    • while 문에서 서로 끊임 없이 양보하는 상황 발생 가능

Algorithm 3 (Peterson's Algorithm)

  • turn과 flag[] 변수 모두 사용
  • Process Pi
  • 두 프로세스 모두가 Critical section에 들어가고 싶을 경우에만 turn 변수를 따지는 구조
  • 세 가지 요구사항을 모두 만족하지만, Busy Waiting(=Spin Lock) 문제
    • CPU와 Memory를 계속 사용하면서 대기 !

Synchronization Hardware

  • Interrupt는 Instruction 단위로 발생
    • Instruction 하나에 읽기와 쓰기가 가능해진다면?
    • 하드웨어적으로 Test & modifyatomic하게 수행할 수 있도록 지원하는 경우, 문제의 해결 가능

  • a가 0이든 1이든 a를 읽은 후, 1로 변경
  • Mutual Exclution with Test & Set

Semaphores

  • 이전 방식들을 추상화시킨 방법
  • Semaphore S(자원의 갯수)
    • integer variable
    • 아래의 두 가지 atomic 연산에 의해서만 접근 가능

  • P 연산은 자원을 가져가는 행위
  • V 연산은 자원을 반납하는 행위

Block / Wakeup Implementation

  • Semaphore를 다음과 같이 정의

  • block과 wakeup를 다음과 같이 가정
    • block: 커널은 block을 호출한 프로세스를 suspend. 이 프로세스의 PCB를 semaphore에 대한 wait queue에 넣음
    • wakeup(P): block된 프로세스 P를 wakeup 시킴. 이 프로세스의 PCB를 ready queue로 옮김
  • Semaphore 연산은 다음과 같이 정의됨
  • cf. S.value를 빼고 잠 들었기 때문에, 내가 value를 내놓았음에도 value가 0 이하라는 것은 누군가가 잠들어 있다는 의미

Busy-wait vs. Block/wakeup

  • Block/wakeup overhead vs. Critical section 길이
    • Critical section의 길이가 긴 경우 Block/wakeup이 적당
    • Critical section의 길이가 매우 짧은 경우 Block/wakeup 오버헤드가 busy-wait 오버헤드보다 더 커질 수 있음
    • 일반적으로는 Block/wakeup 방식이 더 좋음

Two types of Semaphores

  • Counting semaphore
    • 도메인이 이상인 임의의 정수값
    • 주로 resource counting에 사용
  • Binary semaphore(= mutex)
    • 0 또는 1 값만 가질 수 있음
    • 주로 Mutual Exclusion(lock/unlock)에 사용

Deadlock and Starvation

  • Deadlock: 둘 이상의 프로세스가 서로 상대방에 의해 충족될 수 있는 event를 무한히 기다리는 현상

  • 자원을 요구하는 순서의 변경을 통해 해결이 가능
  • Starvation: indefinite blocking. 프로세스가 suspend된 이유에 해당하는 세마포어 큐에서 빠져나갈 수 없는 현상


'Software Convergence > OS, Linux ' 카테고리의 다른 글

7. Deadlocks  (0) 2018.09.25
6. Process Synchronization (2)  (0) 2018.09.25
5. CPU Scheduling  (0) 2018.09.17
4. Process Management  (0) 2018.09.16
3. Process  (0) 2018.09.16

CPU Scheduling

  • 프로그램은 CPU burst와 I/O burst의 연속
  • 혹은 프로그램의 특성상 CPU를 자주 사용하는 혹은 I/O를 많이 필요로 하는 프로그램이 있을 수 있음

  • 여러 종류의 Job(=Process)이 섞여 있기 때문에 CPU 스케줄링이 필요
    • Interactive job에게 적절한 response 제공
    • CPU와 I/O 장치 등 시스템 자원을 효율적으로 사용

프로세스의 특성 분류

  • I/O-bound process
    • CPU를 잡고 계산하는 시간보다 I/O에 많은 시간이 필요한 job
    • many short CPU bursts
  • CPU-bound process
    • 계산 위주의 job
    • few very long CPU bursts

CPU Scheduler & Dispatcher

  • CPU Scheduler
    • Ready 상태의 프로세스 중에서 어떤 프로세스에게 CPU를 줄지 고름
  • Dispatcher
    • CPU의 제어권을 CPU Scheduler에 의해 선택된 프로세스에게 넘김
    • 이 과정을 Context switch라고 함
  • CPU 스케줄링이 필요한 경우는 프로세스에게 다음과 같은 상태 변화가 있는 경우
    1. Running -> Blocked(ex: I/O 요청 시스템 콜)
    2. Running -> Ready (ex: 할당 시간 만료로 timer interrupt)
    3. Blocked -> Ready (ex: I/O 완료 후의 Interrupt)
    4. Terminate
  • 1, 4에서의 스케줄링은 non-preemptive(비선점)
  • 다른 스케줄링은 preemptive(선점)

스케줄링 성능 척도

  • 시스템 입장
    • CPU utilization(이용률)
      • keep the CPU as busy as possible
    • Throughput(처리량)
      • number of processes that complete their execution per time unit
  • 프로세스 입장
    • Turnaround time(반환 시간)
      • amount of time to execute a particular process
    • Waiting time(대기 시간)
      • amount of time a process has been waiting in the ready queue
    • Response time(응답 시간)
      • amount of time it takes from when a request was submitted until the first response is produced(not output) for time-sharing env.
    • Waiting time은 프로세스가 대기했던 총 대기 시간, Response time은 프로세스가 최초로 CPU를 얻기까지의 시간

스케줄링 알고리즘

FCFS (First-Come First-Served)

  • 현실 세계에서 보편적인 처리 과정
  • 비선점(non-preemptive) 알고리즘이자, 효율적이지 않은 알고리즘
  • Convoy effect: CPU를 짧게 쓰는 프로세스들이 CPU를 길게 쓰는 프로세스 뒤에 배치되는 것

SJF (Shortest Job First)

  • 각 프로세스의 다음 번 CPU burst time을 가지고 스케줄링에 활용
  • CPU burst time이 가장 짧은 프로세스를 가장 먼저 스케줄링
  • Two schemes

    • Non-preemptive: 일단 CPU를 잡으면 이번 CPU burst가 완료될 때 까지 CPU를 선점 당하지 않음
    • Preemptive
      • 현재 수행 중인 프로세스의 남은 burst time보다 더 짧은 CPU burst time을 가지는 새로운 프로세스가 도착하면 CPU를 빼앗김
      • 이 방법을 Shortest-Remaining Time First(SRTF)라고도 부름
    • Preemptive가 average waiting time이 더 짧음
  • SJF is optimal
    • 주어진 프로세스들에 대해 Minimun average waiting time을 보장(가장 짧은 평균 대기 시간)
  • SJF의 문제점
    • CPU 사용 시간이 긴 프로세스들에 대한 Starvation의 문제가 있음
    • 다음 CPU Burst time의 예측
      • 다음 번 프로세스의 CPU Burst time을 어떻게 예측할 것인가? (input data, branch ...)
        • 과거의 CPU Burst time을 이용해서 추정(exponential averaging)

Priority Scheduling

  • A priority number is associated with each process
  • highest priority를 가진 프로세스에게 CPU 할당
  • SJF는 일종의 priority scheduling
  • 문제
    • Starvation: low priority processes may never execute
  • 해결 방안
    • Aging: as time progresses increase the priority of the process

Round-Robin

  • 각 프로세스는 동일한 크기의 할당 시간(time quantum)을 가짐
    • 일반적으로 10-100 milliseconds
  • 할당 시간이 지나면 프로세스는 선점 당하고, ready queue의 제일 뒤에 가서 다시 줄을 섬
  • n개의 프로세스가 ready queue에 있고, 할당 시간이 q time unit인 경우, 각 프로세스는 최대 q time unit 단위로 CPU 시간의 1/n을 얻음
    • 어떤 프로세스도 (n-1)q time unit 이상 기다리지 않음!
  • Performance
    • q large -> FCFS
    • q small -> Context Switch 오버헤드가 커짐
  • 극단적 예
    • 같은 수행 시간을 지닌 프로세스들을 짧은 Time quantum으로 쪼개면 긴 Waiting time, Turnaroun time을 지니게 되어 굉장히 비효율적이 될 수 있음
    • 어느 하나의 프로세스도 빨리 빠져나가지 못하고 계속 짧은 구간을 반복적으로 수행해야 하기 때문!

Multi-Level Queue

  • Ready Queue를 여러 개로 분할
    • foreground(interactive)
    • background(batch - no human interaction)
  • 각 Queue는 독립적인 스케줄링 알고리즘을 가짐
    • foreground - RR
    • background - FCFS
  • Queue에 대한 스케줄링이 필요
    • Fixed priority scheduling
      • serve all from foreground then from background
      • possibility of Starvation
    • Time slice
      • 각 queue에 CPU time을 적절한 비율로 할당
      • 80% to foreground in RR, 20% to background in FCFS

Multi-Level Feedback Queue

  • 프로세스가 다른 queue로 이동이 가능
  • Aging을 이와 같은 방식으로 구현 가능
  • Multilevel Feedback queue Scheduler를 정의하는 Parameters
    • Queue의 수
    • 각 Queue의 Scheduling Algorithm
    • 프로세스를 상위/하위 queue로 보내는 기준

Multiple-Processor Scheduling

  • CPU가 여러 개인 경우 스케줄링은 더욱 복잡해짐
  • Homogeneous processor인 경우
    • Queue에 한 줄로 세워서 각 프로세서가 알아서 꺼내가게 할 수 있음
    • 반드시 특정 프로세서에서 수행되어야 하는 프로세스가 있는 경우에는 문제가 더 복잡해짐
  • Load sharing
    • 일부 프로세서에 Job이 몰리지 않도록 부하를 적절히 공유하는 메커니즘 필요
    • 별개의 Queue를 두는 방법 vs. 공동 Queue를 사용하는 방법
  • Symmetric Multiprocessing
    • 각 프로세서가 각자 알아서 스케줄링 결정
  • Asymmetric Multiprocessing
    • 하나의 프로세서가 시스템 데이터의 접근과 공유를 책임지고, 나머지 프로세서는 거기에 따름

Real-Time Scheduling

  • Hard real-time systems
    • 정해진 시간 안에 반드시 끝내도록 스케줄링
  • Soft real-time computing
    • 일반 프로세스에 비해 높은 우선순위를 갖도록 해야 함

Thread Scheduling

  • Local Scheduling
    • User level thread의 경우 사용자 수준의 thread library에 의해 어떤 thread를 스케줄링할지 결정
  • Global Scheduling
    • Kernel level thread의 경우 일반 프로세스와 마찬가지로 Kernel의 단기 스케줄러가 어떤 thread를 스케줄링할지 결정

Algorithm Evaluation

  • Queueing models
    • 확률 분포로 주어지는 arrival rate와 service rate 등을 통해 각종 performance index 값을 계산
  • Implementation & Measurement
    • 실제 시스템에 알고리즘을 구현하여 실제 작업에 대해서 성능을 측정 비교
  • Simulation
    • 알고리즘을 모의 프로그램으로 작성 후, trace를 입력으로 하여 결과 비교
    • 다양한 Test case를 사용하여 돌려봐야 함


'Software Convergence > OS, Linux ' 카테고리의 다른 글

6. Process Synchronization (2)  (0) 2018.09.25
6. Process Synchronization (1)  (0) 2018.09.20
4. Process Management  (0) 2018.09.16
3. Process  (0) 2018.09.16
2. System Structure & Program Execution  (0) 2018.09.16

Process Management

프로세스 생성

  • 부모 프로세스가 자식 프로세스 생성
  • 프로세스의 Tree(계층 구조) 형성
  • 프로세스는 자원을 필요로 함
    • 운영체제로 부터 받음
    • 부모와 공유
  • 자원의 공유
    1. 부모와 지식이 모든 자원을 공유하는 모델
    2. 일부를 공유하는 모델
    3. 전혀 공유하지 않는 모델(common)
  • 수행(Execution)
    • 부모와 자식이 공존하며 수행되는 모델
    • 자식이 종료될 때 까지 부모가 기다리는 모델
  • 주소 공간(Address space)
    • 자식은 부모의 공간을 복사(binary & OS data)
    • 자식은 그 공간에 새로운 프로그램을 올림
  • UNIX의 예
    • fork() 시스템 콜이 새로운 프로세스 생성
      • 부모를 그대로 복사 (binary + OS data except PID)
      • 주소 공간 할당
    • fork 다음에 이어지는 exec() 시스템 콜을 통해 새로운 프로그램을 메모리에 올림

프로세스 종료

  • 자발적: 프로세스가 마지막 명령을 수행한 후, 운영체제에게 이를 알려줌(exit)
    • 자식이 부모에게 output data를 보냄(via wait)
    • 프로세스의 각종 자원들이 운영체제에게 반납됨
  • 비자발적: 부모 프로세스가 자식의 수행을 종료시킴(abort)
    • 자식이 할당 자원의 한계치를 넘어섬
    • 자식에게 할당된 Task가 더 이상 필요하지 않음
    • 부모가 종료(exit)하는 경우
      • 운영체제는 부모 프로세스가 종료하는 경우 자식이 더 이상 수행되도록 두지 않음
      • 단계적 종료: 최하단 자식 프로세스부터 윗 단계로 단계적 종료

fork() 시스템 콜

  • A process is created by the fork() system call
  • create a new address space that is a duplicate of the caller
  • 자식 프로세스는 fork() 이후부터의 프로그램 실행
    • 부모 프로세스의 문맥(PC)이 fork() 실행 이후로 저장되기 때문!
int main()
{
    int pid;
    pid = fork();
    if (pid == 0) // this is child
        printf("\n Hello, I am child!\n");
    else if (pid > 0) // this is parent
        printf("\n Hello, I am parent!\n");
}

exec() 시스템 콜

  • A process can execute a different program by the exec() system call
  • replaces the memory image of the caller with a new program
int main()
{
    int pid;
    pid = fork();
    if (pid == 0) // this is child
    {
        printf("\n Hello, I am child! Now I'll run date \n");
        execlp("/bin/date", "/bin/date", (char *) 0);
    }
    else if (pid > 0) // this is parent
        printf("\n Hello, I am parent\n");
}
  • 반드시 자식을 만들어서 exec()을 할 필요는 없음
    • 부모 프로세스도 exec()으로 다른 프로그램 실행 가능
int main()
{
    printf("\n Hello! Now I'll run date \n");
    execlp("/bin/date", "/bin/date", (char *) 0);
    printf("\n Hello! I am back!\n");
}
  • 위 예제에서 exec()으로 완전히 다른 프로그램으로 바뀌었기 때문에 3번 째 printf문은 실행되지 않음

wait() 시스템 콜

  • 프로세스 A가 wait() 시스템 콜을 호출하면,
    • kernel은 child가 종료될 때 까지 프로세스 A를 sleep 시킴(Blocked)
    • Child 프로세스가 종료되면 kernel은 프로세스 A를 깨움(Ready)
  • 쉘에서 프로그램을 실행시키는 것이 wait() 시스템 콜의 예
    • 쉘이 프로그램을 자식 프로세스로 실행시키고,
    • 해당 프로세스가 종료될 때 까지 wait()

exit() 시스템 콜

  • 자발적 종료
    • 마지막 statement 수행 후, exit() 시스템 콜을 통해
    • 프로그램에 명시적으로 적어주지 않더라도 main 함수가 return 되는 위치에 컴파일러가 넣어줌
  • 비자발적 종료
    • 부모 프로세스가 자식 프로세스를 강제 종료
      • 자식 프로세스가 한계치를 넘엇는 자원 요청
      • 자식에게 할당된 Task가 더 이상 필요하지 않음
    • 키보드로 kill, break 등을 입력한 경우
    • 부모가 종료하는 경우
      • 부모 프로세스가 종료하기 전에 자식들이 먼저 종료됨

프로세스 간 협력

  • 독립적 프로세스
    • 프로세스는 각자의 주소 공간을 가지고 수행되므로 원칙적으로 하나의 프로세스는 다른 프로세스의 수행에 영향을 미치지 못함
  • 협력 프로세스
    • 프로세스 협력 메커니즘을 통해 하나의 프로세스가 다른 프로세스의 수행에 영향을 미칠 수 있음
  • 프로세스 간 협력 메커니즘(IPC: Interprocess Communication)

  • 메시지를 전달하는 방법

    • message passing: 커널을 통해 메시지 전달
    • 주소 공간을 공유하는 방법
      • shared memory: 서로 다른 프로세스 간 일부 주소 공간을 공유하게 하는 메커니즘
        • shared memory의 사용을 위해서는 해당 프로세스들이 신뢰할 수 있는 관계여야 함
  • Thread는 사실상 하나의 프로세스이므로 프로세스 간 협력으로 보기는 어렵지만 동일한 프로세스를 구성하는 Thread들 간에는 주소 공간을 공유하므로 협력이 가능

Message Passing

  • Message system
    • 프로세스 사이에 공유 변수를 일체 사용하지 않고 kernel을 통해 통신하는 시스템

'Software Convergence > OS, Linux ' 카테고리의 다른 글

6. Process Synchronization (1)  (0) 2018.09.20
5. CPU Scheduling  (0) 2018.09.17
3. Process  (0) 2018.09.16
2. System Structure & Program Execution  (0) 2018.09.16
1. Introduction to Operating Systems  (0) 2018.09.16

Process

프로세스의 개념

  • Process is a progam in execution
  • 프로세스의 문맥(context)
    • CPU 수행 상태를 나타내는 하드웨어 문맥
      • Program Counter
      • 각종 register
    • 프로세스의 주소 공간
      • code, data, stack
    • 프로세스 관련 커널 자료 구조
      • PCB(Process Control Block)
      • Kernel stack

프로세스의 상태

  • 프로세스는 지속적으로 상태가 변경되며 수행됨
  • Running: CPU를 할당 받아 명령을 수행 중인 상태
  • Ready: 메모리 등 다른 조건을 모두 만족하고 CPU를 기다리는 상태
  • Blocked(wait, sleep)
    • CPU를 주어도 당장 명령을 수행할 수 없는 상태
    • 프로세스 자신이 요청한 Event(ex: Disk I/O)가 즉시 만족되지 않아, 이를 기다리는 상태
  • New: 프로세스가 생성 중인 상태
  • Terminated: 수행이 끝난 상태

  • CPU를 사용하지 못하고 있는 이유는 위와 같이 다양함
  • Ready, Block Queue 관련 정보는 Kernel의 Data 영역에 저장됨

PCB(Process Control Block)

  • 운영체제가 각 프로세스를 관리하기 위해 프로세스 당 유지하는 정보로 구조체로 유지
  • (1) OS가 관리상 사용하는 정보
    • Process state, PID
    • scheduling information, priority..
  • (2) CPU 수행 관련 하드웨어 값
    • PC, registers
  • (3) 메모리 관련
    • code, data, stack의 위치 정보
  • (4) 파일 관련
    • Open file descriptors

Context Switch

  • CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정
  • CPU가 다른 프로세스에게 넘어갈 때 운영체제는 다음을 수행
    • CPU를 내어주는 프로세스의 상태를 그 프로세스의 PCB에 저장
    • CPU를 새롭게 얻는 프로세스의 상태를 PCB에서 읽어옴
  • System call이나 Interrupt 발생 시 반드시 문맥 교환이 일어나는 것은 아님



프로세스를 스케줄링하기 위한 Queue

  • Job Queue: 현재 시스템 내에 있는 모든 프로세스의 집합
  • Ready Queue: 현재 메모리 내에 있으면서 CPU를 할당 받아 실행되기를 기다리는 프로세스의 집합
  • Device Queues: I/O device의 처리를 기다리는 프로세스의 집합
  • 프로세스들은 위의 Queue들을 오가며 수행됨

Scheduler

  • Long-term scheduler(Job scheduler)
    • 시작 프로세스 중 어떤 것들을 ready queue로 보낼지 결정
    • 프로세스에 memory 및 각종 자원을 주는 문제
    • degree of Multiprogramming을 제어
      • 메모리에 올라가 있는 프로세스의 수
      • 메모리에 너무 적은 혹은 너무 많은 프로세스가 있지 않도록 제어
    • time sharing system에는 보통 장기 스케줄러가 없음
      • 무조건 ready queue로 보냄!
      • Swapper가 degree of Multiprogramming을 제어
  • Short-term scheduler(CPU scheduler)
    • 어떤 프로세스를 다음에 running 시킬지 결정
    • 프로세스에게 CPU를 주는 문제
    • millisecond 단위로 충분히 빨라야 함
  • Medium-term scheduler(Swapper)
    • 여유 공간 마련을 위해 프로세스를 통째로 메모리에서 디스크로 쫓아냄
    • 프로세스에게서 memory를 빼앗는 문제
    • degree of Multiprogramming을 제어

  • Swapper로 인해 추가되는 프로세스 상태 Suspended(stopped)
    • 외부적 이유로 프로세스의 수행이 정지된 상태
    • 프로세스는 통째로 디스크에 Swap out 됨
    • 외부에서 resume해 주어야 다시 Active
  • cf. 메모리에 너무 적은 프로세스만 올라가 있으면 왜 안좋은가?
    • 모든 프로세스들이 device queue에 들어가게 되면 CPU는 노는 상태가 되버림

Thread

  • A Thread(lightweight process) is a basic unit of CPU utilization

  • Thread의 구성(독립적으로 가지는 요소)
    • Program counter
    • Register set
    • Stack space
  • Thread가 동료 Thread와 공유하는 부분(Task)
    • Code section
    • Data section
    • OS resources
  • 즉, 공유할 수 있는 것은 최대한 공유하고, CPU 수행단위를 여러 개를 두는
  • Thread의 종류
    • kernel에 의해 지원되는 Kernel Threads
      • Thread가 여러 개 있다는 것을 kernel이 알고 있음
      • 따라서, context switch가 매우 빠름
    • library를 통해 지원되는 User Threads
      • Thread가 여러 개 있다는 것을 kernel은 모르고 사용자 프로그램이 관리해야 함
    • 이 외에도 Realtime thread도 존재

Thread의 장점

  • 응답성: 다중 Thread로 구성된 Task 구조에서는 하나의 서버 Thread가 Blocked(wait) 상태인 동안에도 동일한 Task 내의 다른 Thread가 Running이 되어 빠른 처리를 할 수 있음
    • ex) 웹 브라우저 프로세스를 구성하는 하나의 Thread가 이미지를 불러오는 동안에, 또 다른 Thread가 이미 읽어온 HTML 문서와 같은 것들을 미리 화면에 제공..
  • Resource Sharing: n개의 Threads는 하나의 프로세스의 binary code, data, resource를 공유
  • Economy: 동일한 일을 수행하는 다중 Thread가 협력하여 높은 Throughput과 성능 향상을 얻을 수 있음
    • thread 간 문맥 교환도 같은 process 내에서 일어나기 때문에 빠름
    • ex) Word 프로그램에서 여러 파일을 띄워놓을 때, 각각의 파일을 프로세스를 생성하여 수행하도록 하는 것이 아니라 Thread를 생성하여 성능 향상
  • Utilization of Multi Processor Architectures: 각각의 Thread는 여러 개의 프로세서에서 병렬적으로 running되어 병렬성을 높일 수 있음


'Software Convergence > OS, Linux ' 카테고리의 다른 글

5. CPU Scheduling  (0) 2018.09.17
4. Process Management  (0) 2018.09.16
2. System Structure & Program Execution  (0) 2018.09.16
1. Introduction to Operating Systems  (0) 2018.09.16
Linux Command Line Guide(2)  (0) 2018.09.10

System Structure & Program Execution

컴퓨터 시스템 구조

  • CPU는 매 클록 주기 마다 Memory에서 명령어를 읽어와 명령 수행

  • Memory는 CPU의 작업 공간
  • 사용자 프로그램이 I/O 요청할 때는 운영체제에게 CPU를 넘기고, 요청한 작업이 끝나 결과를 받을 때 까지 대기
    • 그 동안 CPU는 다른 프로그램을 수행
    • CPU는 매 프로그램의 종료 이후, 들어온 Interrupt가 있는지 확인

Mode bit

  • 사용자 프로그램의 잘못된 수행으로 다른 프로그램 및 운영체제에 피해가 가지 않도록 하기 위한 보호장치가 필요

  • Mode bit을 통해 하드웨어적으로 2가지 모드의 Operation 지원

    • 사용자 모드(1): 사용자 프로그램 수행
      • 제한된 접근, 프로그램의 수행만 가능
    • 커널 모드(0): OS 코드 수행
      • 모든 접근, 프로그램의 수행이 가능
  • 보안을 해칠 수 있는 중요한 명령어는 커널 모드에서만 수행 가능한 특권 명령으로 규정
  • Interrupt나 Exception 발생 시, 하드웨어가 mode bit을 0으로 세팅
  • 사용자 프로그램에게 CPU를 넘기기 전에 mode bit을 1로 세팅

Timer

  • CPU를 특정 프로그램이 독점하는 것으로부터 보호
  • 정해진 시간이 흐른 뒤, 운영체제에게 제어권이 넘어가도록 Interrupt를 발생시킴
  • Timer는 매 Clock tick 마다 1씩 감소
  • Timer 값이 0이 되면 Timer Interrupt 발생
  • Timer는 Time Sharing을 구현하기 위해 널리 이용됨
  • 또한, 현재 시간을 계산하기 위해서도 사용

Device Controller

  • 각 I/O 장치 유형을 관리하는 일종의 작은 CPU
  • 제어 정보를 위해 Control, Status register를 가짐
  • I/O 장치의 결과를 저장하기 위한 Local buffer를 가짐
  • I/O는 실제 Device와 Local buffer 사이에서 일어남
  • Device Controller는 I/O가 끝났을 경우, Interrupt로 CPU에 그 사실을 알림
  • Device Driver(장치 구동기): OS 코드 중 각 장치별 처리 루틴 -> Software

I/O의 수행

  • 모든 입출력 명령은 특권 명령 through.OS
  • 사용자 프로그램은 어떻게 I/O를 하는가?
    • System Call
      • 사용자 프로그램이 운영체제의 서비스를 받기 위해 커널 함수를 호출하는 것
    • Trap을 사용하여 인터럽트 벡터의 위치로 이동
    • 제어권이 인터럽트 벡터가 가리키는 인터럽트 서비스 루틴으로 이동
    • 올바른 I/O 요청인지 확인 후, I/O 수행
    • I/O 완료 시, 제어권을 System Call 다음 명령으로 옮김
  • 즉, I/O의 수행을 위해서는 2가지 인터럽트가 걸리는 것
    • I/O 요청 시의 Software Interrupt + I/O 완료 시의 Hardware Interrupt

Interrupt

  • 인터럽트 당한 시점의 Register와 PC를 저장한 후, CPU의 제어를 인터럽트 처리 루틴에 넘김
  • Interrupt: 하드웨어가 발생시킨 인터럽트
  • Trap: 소프트웨어가 발생시킨 인터럽트
    • Exception: 프로그램이 오류를 범한 경우
      • ex) 운영체제의 메모리 접근, divide by zero
    • System call: 프로그램이 커널 함수를 호출하는 경우
  • 인터럽트 관련 용어
    • 인터럽트 벡터: 해당 인터럽트의 처리 루틴 주소를 가지고 있음
    • 인터럽트 처리 루틴(인터럽트 핸들러): 해당 인터럽트를 처리하는 커널 함수

동기식 입출력과 비동기식 입출력

  • 동기식 입출력(Synchrounous I/O)
    • I/O 요청 후, 입출력 작업이 완료된 후에야 제어가 사용자 프로그램에 넘어감
    • 구현 방법 1
      • I/O가 끝날 때 까지 CPU를 낭비
      • 매 시점 하나의 I/O만 일어날 수 있음
    • 구현 방법 2
      • I/O가 완료될 때 까지 해당 프로그램에게서 CPU를 빼앗음
      • I/O 처리를 기다리는 줄에 그 프로그램을 줄 세움
      • 다른 프로그램에게 CPU를 줌
      • I/O 요청이 끝나면 바로 요청했던 프로그램에게 CPU를 넘겨줌
  • 비동기식 입출력(Asynchrounous I/O)
    • I/O가 시작된 후, 입출력 작업이 끝나기를 기다리지 않고 제어가 사용자 프로그램에 즉시 넘어감
  • 두 경우 모두 I/O의 완료는 Interrupt로 알려줌
  • I/O 결과가 다음 명령어 실행에 영향을 미치는 경우, 동기식 입출력을
  • 그렇지 않을 경우, 비동기식 입출력을 사용할 수 있음

DMA(Direct Memory Access)

  • 빠른 입출력 장치를 메모리에 가까운 속도로 처리하기 위해 사용
  • CPU의 중재 없이 Device controller가 device의 Buffer storage 내용을 메모리에 Block 단위로 직접 전송
  • Byte 단위가 아니라 Block 단위로 Interrupt 발생시킴

서로 다른 입출력 명령어

  1. Using I/O instruction: 메모리 접근하는 명령어 따로, I/O 장치 접근하는 명령어를 따로 두는 명령어 방식
  2. Memory Mapped I/O: I/O 장치들에 메모리 주소를 메겨, 메모리의 연장 선상으로 사용하는 방식

프로그램의 실행 (메모리 Load)

  • 프로그램은 '실행 파일' 형태로 File System에 저장
  • 각 프로그램은 프로세스로 변환되면서 고유의 Address space 형성
    • code, data, stack 등으로 구성
    • Kernel 역시 주소 공간을 형성하여 메모리에 올라감
  • 각 프로세스는 Address translation을 통해 Physical memory에 탑재
  • 프로그램의 실행을 위해 Memory에 올라가있을 필요가 없는 메모리들은 Swap area(HDD)에 내려 놓음
    • 일종의 Memory 연장 공간

커널 주소 공간의 내용

  • 어떤 사용자 프로그램이 커널 코드를 실행 중인지에 대해 알기 위해 프로세스 마다 커널 스택을 따로 둠

사용자 프로그램이 사용하는 함수

  • 사용자 정의 함수
    • 자신의 프로그램에서 정의한 함수
  • 라이브러리 함수
    • 자신의 프로그램에서 정의하지 않고 가져다 쓰는 함수
    • 자신의 프로그램의 실행 파일에 포함되어 있음
  • 커널 함수
    • 운영체제 프로그램의 함수
    • 커널 함수의 호출 = 시스템 콜


모든 출처는 반효경 교수님 운영체제 강의

'Software Convergence > OS, Linux ' 카테고리의 다른 글

4. Process Management  (0) 2018.09.16
3. Process  (0) 2018.09.16
1. Introduction to Operating Systems  (0) 2018.09.16
Linux Command Line Guide(2)  (0) 2018.09.10
vimtutor 내용 정리  (0) 2018.09.09

+ Recent posts