'공부/운영체제'에 해당되는 글 13건

  1. 2011.07.13 I/O System
  2. 2011.07.13 Mass-storage structure
  3. 2011.07.13 File System Implementation
  4. 2011.07.13 File System
  5. 2011.07.13 Virtual Memory
  6. 2011.07.10 8장 Memory-management strategies
  7. 2011.07.09 7장 Deadlock
  8. 2011.07.04 6장 Synchronization
  9. 2011.07.03 Process scheduling
  10. 2011.06.30 Multithreaded Programming
공부/운영체제2011. 7. 13. 22:35


I/O hardware

Port : 연결지점. 대개 register.
Bus: 선들과 커뮤니케이션 프로토콜. Data bus, Address bus
Controller : port, bus, 장치 제어

Daisy chain
장치들이 서로 직렬로 연결되어 있는 구조.

I/O Registers

I/O port는 보통 4개의 레지스터로 구성되어 있다. 
1) status register : 현재 명령이 처리되었는지, data-in register에서 읽을 수 있는지, 장치에 문제가 있는지 등이 저장된다.
2) control register : host에 의해 씌여진 명령어가 들어있다.
3) data-in register : host가 읽는 register
4) data-out register : host가 쓰는 register

I/O와 Memory 컨트롤

1) memory-mapped I/O

memory랑 I/O가 Data bus, Address bus, control bus를 공유한다.
그래서 같은 명령어로 접근할 수 있다.
2) Isolated I/O
Data bus와 Address bus를 공유하지만 Control bus는 공유하지 않는다.
그래서 서로 다른 명령어를 사용한다.
3) Data Channel
Data bus, Address bus, Control bus를 다 따로 쓴다.
I/O 전용 프로세서가 있다.

Isolated I/O는 두개의 주소공간을 사용한다.(메모리 주소공간, I/O주소공간)
I/O-mapped I/O라고도 한다.

memory mapped i/o는 주소공간에서 주소공간에서 특정위치를 가지고 있다.
I/O를 읽고 쓰는 건지 메모리를 읽고 쓰는건지 control이 가능해야 한다.

PC는 i/o mapped i/o랑 memory-mapped i/o를 모두 사용한다.
그래픽 컨트롤러는 기본 제어 명령을 위한 i/o ports가 있고 화면 정보를 위한 memory-mapped 영역을 가지고 있다.
memory-mapped는 pointer가 잘못된 주소를 가졌을 때 문제가 발생하기 쉽다. protected memory로 보호해야 한다.

두가지 종류의 I/O

1) Polling (programmed I/O)

CPU가 I/O를 직접 제어한다.
CPU는 I/O모듈이 명령을 완료하길 기다린다.
busy waiting(polling)
루프돌면서 state 레지스터의 busy bit가 clear될 때까지 기다리는 것.
과정
host가 write bit을 set하고 data-out register에 byte 쓰고 command-ready bit을 set한다. controller는 command-ready bit을 보고 busy bit을 셋하고 command register를 읽고 write명령을 알게된다. data-out 레지스터에서 byte를 읽고 장치에 입출력처리를 한다. controller는 status register의 command-ready bit을 clear하고, error bit도 clear해서 I/O가 완료되었음을 알린다. 그리고 busy bit을 clear한다.

2) Interrupts(Interrupt-Driven I/O)

cpu가 read command를 알린다.
I/O 모듈은 데이터를 얻는다. 그동안 CPU는 다른 일을 하고 있고
I/O는 CPU에게 인터럽트를 날린다.
CPU는 데이터를 요청한다.
I/O 모듈은 데이터를 전송한다.

Direct Memory Access(DMA)

interrupt driven과 programmed i/o는 활발한 cpu 사용을 요구한다. cpu가 이러한 일 하기에는 아깝고 해서
DMA가 일을 대신해준다.
I/O 장치와 메모리 사이에서 CPU를 거치지 않고 데이터를 전송해준다.

State Transition
응용프로그램 I/O 요청 -> OS는 그 프로그램을 block 상태에 놓는다. -> DMA에게 맡기고 CPU는 다른 프로그램을 실행한다. DMA가 그 일을 완료했으면 CPU에게 인터럽트를 보내고 OS는 다시 그 중지된 프로그램을 runnable한 상태로 바꾼다.

DMA가 메모리 버스를 쓰고 있더라도 CPU는 캐시를 통해 데이터를 읽을 수 있다.

Application I/O Interface
운영체제가 여러 i/O 장치들을 표준화된 동일한 방식으로 다루게 하는 기술들과 인터페이스들을 살펴보자.

I/O system calls은 장치에 사용될 수 있는 기능들을 캡슐화한 것임.
Device-driver는 i/O controller간의 차이를 못느끼게 해준다.

Device는 다음과 같은 차원에서 생각할 수 있다.
1) Character-stream과 block(byte단위로 전송하냐 block 단위로 전송하냐)
2) Sequential or random-access
3) Synchronous or asynchronous(장치의 데이터 전송시간이 예측가능하냐 아니냐)
4) Sharable or dedicated (여러 프로세스나 쓰레드에 의해 동시에 사용될 수 있나 없나)
5) Speed of operation (일초에 몇 바이트냐, 몇 기가바이트냐)
6) Read-write, read only, or write only

Network devices

Block, character device가 아니다. 예외.
socket 인터페이스 사용.

Clocks and Timers

시간 장치.
현재시간, 경과시간, x명령이 y시간에 발생하도록 하는 타이머 지정 함수 제공
programmable interval timer
특정 시간동안 기다렸다가 인터럽트를 발생시키는 것.
한번, 또는 주기적으로 발생하도록 할 수 있다.
disk I/O subsystem에서는 이것을 dirty bit cache buffers를 disk로 옮길 때 주기적으로 사용한다.
network subsystem이 너무 느리게 진행되는 명령을 취소하는데 사용된다.

Kernel I/O subsystem
I/O를 위해 커널에서 제공하는 서비스들

Scheduling

한 장치에 여러 request가 들어올 때 O/S에서 스케줄링. 보통 FIFO를 하나, 시스템 효율을 위해 바꿀 수도 있다.

Buffering
3가지 목적

device speed dismatch
모뎀에서 데이터를 하드디스크로 보낼 때, 둘이 속도차이가 크기 때문에 모뎀에서 버퍼에 쓰고 일정양이 모이면 하드가 읽어간다. 하드가 읽어가는 게 금방 끝나는게 아니라서 double buffering을 쓴다. buffer가 두개라 모뎀이 한 buffer를 채우면 하드가 그걸 읽고 하드가 읽는 동안 모뎀은 두번째 버퍼를 채운다.

transfer size mismatch
전송 단위가 다를때 버퍼에서 쪼개거나, 합쳐서 단위를 맞춰준다.
컴퓨터 네트워킹에서 긴메시지가 패킷으로 쪼개지고, 쪼개진게 다시 합쳐지는 과정이 버퍼에서 일어난다.

copy semantics
disk에 저장되는 데이터가 어플리케이션에서 시스템콜이 호출될 때의 데이터와 같도록 보장해주는것.
어플리케이션의 버퍼가 write 시스템콜이 호출된 뒤 바뀌더라도 디스크에는 바뀌기 전 버퍼의 데이터가 저장되도록 보장해준다. 어플리케이션의 버퍼를 커널 버퍼로 복사해줌으로써 가능해진다.

caching
데이터의 복사본을 빠른 메모리에 유지하고 있기
성능향상

Spooling
프린터같은 장치를 위해 output을 유지시켜주는 버퍼이다. 프린터는 한번에 한작업밖에 할 수 없기 때문에 운영체제가 여러 프로그램에서 요청한 output을 file로 만들어 큐에다가 저장하고 있다가 printer에게 한번에 하나씩 복사한다. 유저나 관리자가 큐를 볼 수있고, 작업을 제거하거나, 중지시킬 수 있다.

Error Handling
운영체제는 장치의 일시적인 문제로 작동이 안될 때 처리할 수 있는 방법을 제공한다.

 

'공부 > 운영체제' 카테고리의 다른 글

Mass-storage structure  (0) 2011.07.13
File System Implementation  (0) 2011.07.13
File System  (0) 2011.07.13
Virtual Memory  (0) 2011.07.13
8장 Memory-management strategies  (0) 2011.07.10


Posted by skyjumps
공부/운영체제2011. 7. 13. 22:35


디스크 구조.

실린더, 트랙, 섹터
섹터단위로 데이터 저장.
가장 바깥쪽 실린더에 첫번째 트랙의 첫번째 섹터부터 데이터 저장.
track을 따라 저장되다가 같은 실린더의 다른 track을 따라 저장되다가 실린더 바깥쪽에서 안쪽으로 간다.

logical block의 1차원 배열이 디스크의 섹터로 순서대로 매핑된다.

매핑하는데 어려운 점들
 

디스크에 불량섹터가 있을 경우
트랙당 섹터 수가 균일하지 않은 문제 
트랙당 섹터 밀도수가 다를 때
같은 데이터 전송률을 유지하기 위해서는  바깥쪽에서 안쪽으로 갈 때 회전 속도를 증가시킨다.
 
Disk scheduling

운영체제는 Disk scheduling를 통해 빠른 access time, 큰 disk bandwidth가 되도록 한다.
access time를 결정하는 두가지 주요요소 
seek time(디스크 헤더를 원하는 섹터가 있는 실린더로 옮길 때 드는 시간)
rotational latency( disk가 원하는 섹터를 헤더에 오도록 판을 돌리는 데 걸리는 시간)
disk bandwidth 전체 전송된 바이트 수/서비스 요청에서 마지막 전송까지 걸린 시간
Disk scheduling으로 access time과 disk bandwidth를 향상 가능하다.

FCFS(first come first service)
선착순 방법. 요청큐에 들어온 순으로 처리.

SSTF(shortest seek time first)
현재 head 위치에서 seek time을 가장 최소로 하는 요청을 처리.
starvation문제 가능성.

SCAN
디스크암이 디스크 끝에서 다른 끝으로 움직인다. 움직이면서 각 실린더에 도달할 때마다 요청된 것을 처리한다. 디스크 끝에 도달하면 방향을 반대로 바꾼다.

C-SCAN
Circular scan
헤드가 디스크 처음부터 끝까지 요청들을 처리하면서 움직이는데 돌아올때는 요청들을 처리하지 않고 바로 처음으로 돌아간다.
더 균일한 wait time을 제공한다.
 
LOOK, C-LOOK
disk의 맨 끝까지 가지 않고 요청된 곳까지만 간다.

어떤 알고리즘을 써야 하나?

sstf나 look이 기본적인 알고리즘으로 괜찮은 선택.
디스크가 헤비로드일때 scan이나 c-scan이 괜찮음. 이 두개가 starvation에 영향을 덜 받기 때문에.
file allocation 방식에 영향을 많이 받을 수 있다. contiguously allocated file은 헤드 움직임이 적고, linked나 indexed file은 head가 많이 움직임.
directory와 index block의 위치도 영향을 미친다. 자주 읽히기 때문이다. 
os가 rotational latency를 줄일 수 있는 방법은 없다. 위 방식들은 seek time을 줄인다.

디스크 관리
disk formatting

low-level-formatting(physical formatting)

디스크를 디스크 컨트롤러가 읽고 쓸 수 있도록 섹터로 나누는 것.
하나 이상의 실린더 그룹으로 파티션을 나눈다.

logical formatting 
파티션을 나눈 후 파티션에 파일 시스템을 넣는 과정
FAT 또는 inodes. 비어있는 directory.

Boot block

bootstrap program

시스템을 초기화 (CPU 레지스터, 디바이스 컨트롤러, 메인 메모리 내용)
초기화 후 운영체제 실행
bootstrap은 디스크에서 시스템커널을 찾고, 커널을 메모리에 올리고, 운영체제 실행 처음 주소로 점프한다.
bootstrap은 ROM(read-only memory)에 저장된다.
대부분 시스템은 bootstrap 프로그램이 디스크로부터 full bootstrap program을 불러오는 기능만 ROM에 있어서 full bootstrap program을 쉽게 변경할 수 있또록 한다.
full bootstrap program은 boot blocks에 저장된다.
boot partition을 가지고 있는 디스크를 boot disk 또는 system disk라고 한다.

Swap-space management

Virtual memory 시스템에게 최고의 throughput을 제공하기 위한 것.
Virtual memory가 디스크 공간을 메인 메모리의 확장영역으로 사용하는 것.

두가지 swap-space 사용방법
프로그램 전체(프로세스 이미지 전체)를 swap.
page 단위로 swap
물리 메모리 크기에 따라 swap space 크기가 다양함.

두가지 swap-space 위치
1) 파일 시스템에서 하나의 큰 파일로 보는 경우
일반 파일처럼 파일 시스템 과정(디렉토리, 디스크 공간할당)을 거치기 때문에 느리다.

2) 분리된 디스크 파티션으로 보는 경우
file system이나 디렉토리 구조가 없다. 
swap-space storage manager가 블락 할당 관리.
swap은 빨라야 하기 때문에 공간 효율보다는 속도가 빠른 알고리즘을 사용한다.

RAID Structure

Redundant Arrays of Inexpensive Disks

여러개의 디스크를 사용함으로써 성능향상과 데이터의 신뢰도 향상에 쓰인다.

신뢰도 향상에 쓰이는 RAID
Mirroing(Shadowing)
같은 data를 모든 디스크에 중복해서 쓴다.

성능향상에 쓰이는 RAID
여러개 디스크에 병렬로 접근 - 데이터 전송률이 올라간다.
Data striping
bit-level striping
여러 disks에 각 byte의 몇 bits씩 쪼개어 저장한다.
Block-level striping
file의 몇 블락씩 여러 disks에 쪼개어 저장한다.
 

'공부 > 운영체제' 카테고리의 다른 글

I/O System  (0) 2011.07.13
File System Implementation  (0) 2011.07.13
File System  (0) 2011.07.13
Virtual Memory  (0) 2011.07.13
8장 Memory-management strategies  (0) 2011.07.10


Posted by skyjumps
공부/운영체제2011. 7. 13. 22:35


파일 시스템은 여러 단계로 구성되어 있다.

어플리케이션 프로그램 - 로지컬 파일 시스템 - file-organization module -  basic file system - I/O control - devices

Device drivers
메인 메모리와 디스크 사이의 정보 전송
효율을 위해 block단위로 전송된다. (하나의 block은 하나 이상의 sector)

Basic file system
디바이스 드라이버에게 명령을 보낸다.
device driver가 제공하는 함수를 사용한다.
각각의 physical block은 disk의 주소로 구분된다.

File organization module
logical block address를 physical address로 바꾼다.
Free space manager가 할당되지 않은 block들을 관리하고 있다가 요청이 들어오면 File organization module에게 block들을 제공한다.

Logical file system
metadata 정보를 다룬다. (실제 데이터를 제외한 모든 파일에 대한 정보)
FCB(file control block)을 통해 디렉토리 구조를 관리한다.


File system structure를 메모리에 올려놓고 쓰기

 출처 : Operating System Principles seventh edition
(a)는 file을 open할 때, (b)는 read할 때

Virtual File System
서로 다른 파일 시스템들이 같은 파일 시스템에 있는 것처럼 해주는 시스템.
한 시스템콜(예를 들면 open)을 사용해서 여러 파일 시스템을 이용할 수 있도록 한다.

Directory Implementation
효율적인 디렉토리 할당 문제와 디렉토리 관리 알고리즘을 사용해야 한다.
 

파일 디렉토리 구조를 만드는데 사용될 수 있는 자료구조들
Directory Implementation:Linear List
data block을 가리키고 있는 파일이름 리스트
 
삭제된 디렉토리 엔트리를 재사용하기 위한 방법
unused라고 표시를 해놓고, 그것을 free directory entries의 리스트에 붙이고, directory list의 마지막 entry를 unused라고 표시된 곳에 복사한다. 그러면 디렉토리 리스트 길이도 짧아지고, 삭제하는 시간도 줄어들 것이다.

Directory Implementation: Hash Table

hash를 이용한 linear list
찾기, 삽입, 삭제가 빨라진다.
collision문제, chained-overflow hash table로 해결할 수 있다.

Allocation Methods

file에 disk block을 어떻게 할당할 것인가.
공간효율성, 빠른 접근

Contiguous Allocation

각 파일은 디스크에 연속적인 block으로 할당되는 방식
단순하고 seek time이 빨라지는 장점이 있으나
새로운 파일을 위한 공간을 찾기가 어렵다거나, 원래 있던 파일이 증가될 수 없다는 단점이 있다.

Linked Allocation

각 파일은 disk blocks의 linked list이다.
directory는 list의 처음과 끝을 가리키는 포인터를 가지고 있다.
장점
external fragmentation이 없다.
파일 크기가 가변적이어도 상관없다.
단점
순차 접근만 가능하다. 찾을때 파일의 처음부터 시작해야 한다.
block마다 pointer를 위한 공간이 필요하다.
pointer가 깨졌을 경우 문제

File Allocation Table(FAT)

Linked allocation의 개선
FAT의 경우에
각 디스크파티션의 시작 섹션에 table을 둔다.
이 테이블은 파티션 내 모든 disk block 수만큼의 엔트리가 있고 각 엔트리는 파일의 다음 block number값을 갖는다.
디렉토리 entry는 파일의 첫번째 블락 넘버를 가지고 있다.
Random access time이 개선된다. FAT에서 일단 먼저 찾아보면 되니까.

Indexed allocation

모든 포인터를 index block에다가 넣기
각각의 파일들은 자신의 index block을 가지고 있다.
디렉토리는 index block의 위치를 가지고 있다.
포인터가 한두개밖에 없더라도 하나의 block이 할당되어야 하므로 공간낭비문제가 있다.
external fragmentation 없이 direct access를 지원할 수 있다. block이 더 필요하면 free-space manager에게 요청하면 block하나 받아서 index block에 번호 추가시키면 됨. 그리고 index block을 읽으면 어느 block에 순차적으로 탐색안하고 접근할 수 있음.

Index block이 얼마나 커야 하는가
index block이 너무 작으면, 큰 파일을 어떻게 다룰지에 대한 문제가 있다.
Linked scheme - index blocks의 list
Multilevel index - 첫번째 인덱스 블락은 두번째레벨 인덱스 블락을 가리킨다.
Combined scheme(UFS) - inode(FCB)가 가진 15개 index blocks 중에서 12개는 파일의 데이터와 직접 연결하는 index이고(direct blocks), 1개는 하나의 index block을 가리키는 index(single indirect block), 1개는 2개의 index block을 가리키는 index block의 index(double indirect), 나머지 하나는 triple indirect.

Disk Drive, Partitions, and a File System

디스크는 파티션으로 나누어 지고
파티션에는 boot block, super block, inode list, data block으로 이루어져 있다.
boot block은 OS를 로드하고 초기화하는데 필요한 코드들이 들어있고
super block에는 파일 시스템의 메타정보들이 들어있다.
Inode list에는 inode들이 들어있다. 유닉스에서는 directory를 하나의 파일처럼 간주한다.

Free-Space Management

시스템은 free space list를 유지한다.
free disk blocks들이 list에 있다.
리스트 구현 : bit vector, linked list, grouping, counting
bit vector
block i가 free면 0, 아니면 1
디스크 용량이 큰 경우 전체 벡터를 메인메모리에 다 못담는다.
연속적인 공간을 얻기는 쉽다.

linked list
첫번째 블락의 포인터만 가지고 있으면 된다.
연속적인 공간을 얻기 어렵다.
공간이 필요하면 리스트의 첫번째 블락부터 주면 된다.
리스트 탐색이 자주 필요하지 않아서 탐색문제는 크게 문제되지 않는다.

grouping
첫번째 free block에 n개의 free block 주소를 저장한다.
n-1개는 정말 비어있는 block이고 마지막 1개는 또 다른 n개의 free block 주소가 저장되어 있다.
free block을 한번에 많이 찾을 수 있다.

counting
연속적인 할당을 이용한다.
첫번째 free block의 주소와 그 블락 뒤에 몇 개의 free block이 있는지에 대한 정보를 가지고 있는다.

Page Cache and Buffer Cache
 

또다른 성능 향상 방법.
디스크 컨트롤러 내에 local memory가 있는데 cache라고 한다. 한 트랙을 담을 정도의 크기를 가지고 있어서
cpu가 cache에서 읽으면 빠르다.
어떤 시스템은 Buffer cache 이용하고 어떤 시스템은 Page cache이용.
buffer cache는 다시 쓰일 것 같은 block유지.
page cache는 virtual memory 기법이 사용된 것으로 파일 데이터를 block단위가 아니라 page단위로 사용하는 것.

I/O without a unified buffer cache

memory mapped file을 읽을 때, 
virtual memory가 buffer cache랑 데이터를 주고 받을 수 없어서 buffer cache의 내용을 page cache로 복사해야 함.(double caching)

대신에 unified buffer cache를 사용하면 memory mapping과 read, write 시스템콜이 같은 페이지 캐쉬를 사용한다.

Recovery

파일과 디렉토리가 main memory와 disk에 있을 때 시스템이 맛이 가도 data 손실이나 불일치를 막아야 한다.

Log-Structured file system
파일을 디스크에 쓰는 과정이 새로운 블락이 할당되고 inode에 새로운 블락정보와 파일정보를 업데이트 하고, block들이 디스크에 쓰여지는 등 과정이 atomic하지 않기 때문에 중간에 시스템에서 interrupt가 나는 경우 일관성 문제와 정보 손실 문제 등 발생. meta data가 손상될 수도 있고.
Journaling(로그기반 처리)은 database의 transaction 같은 것. 변경 과정을 파일에다가 기록.
파일의 일관성을 유지하기 위해 transaction이 제대로 잘 수행되거나 아님 아예 수행이 안되거나 둘 중하나를 보장한다.
메타데이터에만 적용될 수도 있고 파일에 적용될 수도 있다.

NFS(Network file system)
원격의 다른 컴퓨터 파일 시스템을 쓰는 기술.
패킷에 담아 read, write 같은 명령을 전달.




 

'공부 > 운영체제' 카테고리의 다른 글

I/O System  (0) 2011.07.13
Mass-storage structure  (0) 2011.07.13
File System  (0) 2011.07.13
Virtual Memory  (0) 2011.07.13
8장 Memory-management strategies  (0) 2011.07.10


Posted by skyjumps
공부/운영체제2011. 7. 13. 22:34


파일

추상적인 데이터 타입
OS가 파일에 대한 시스템콜 제공 
파일을 open하면 디스크의 directory 구조에서 내용을 찾고, 메모리에 그 내용을 옮긴다.
close하면 메모리 있는 내용을 디스크에 쓴다.
OS는 open-file table을 가지고 있다.

멀티유저 시스템은 두가지 file table을 가지고 있다.

Per-process table

프로세스 별로 file정보를 가지고 있다.
프로세스 의존적인 정보(현재 파일 포인터, 접근 권한 등)

System-wide table

모든 프로세스와 관련된 파일 정보를 가지고 있다.(디스크에서 위치, 접근 날짜, 파일 크기 등)
Open count- 파일이 open되면 1씩 증가, close되면 감소 

File Type

file type으로 그 파일의 내부 구조를 알 수 있다.
OS가 많은 파일 타입을 지원하면 안좋다.
각각의 파일 타입을 지원하는 코드가 필요한데, 그 구현과 OS크기가 복잡하고 커진다.

모든 OS는 실행파일은 지원해야 한다.

Disk 할당

Logical record unit
Unix는 모든 파일을 바이트의 연속이라 정의했다. 1byte가 단위이다.
Physical record unit
모든 disk 장치들은 block 단위로 수행된다. 예) 512byte가 한블락

Access Method

Sequential Access
파일의 정보가 순서대로 처리된다.
read, write 시스템콜 사용하는 것처럼.

Direct Access
순서없이 record를 읽고 쓸 수 있는 것.
어떤 블락에도 random access가 가능하다.

Directory Structure

파일의 숫자가 많아지다보니 생겼다.

파티션
디스크를 여러개의 파티션으로 나눌 수 있다.
각각의 파티션마다 directory(파일에 대한 정보)가 있다.
여러개 dish를 하나의 partition으로 할 수도 있다.

Single-level directory
모든 파일이 같은 디렉토리에 있는것.
모든 파일은 유일한 이름을 가지고 있어야 한다.

Two-level Directory
사용자 마다 자신의 디렉토리가 있다.
master file directory와 user file directory 두 단계.

Tree-Structured Directories
디렉토리가 파일도 포함하고 서브디렉토리도 포함한다.
디렉토리를 하나의 파일로 본다. (처리방식은 다르다.)

Acyclic-Graph Directories

파일과 디렉토리를 공유할수 있다.
문제점
여러개의 이름을 가진다. shared structure를 한번이상 탐색하지 않게 하고 싶을 때 문제.
파일을 삭제하면 원본없이 포인터만 있게 되는 문제.(그냥 내버려둬서 잘못된파일이름으로 처리하거나, 파일을 삭제하지 않고 유지하는 해결방법이 있다.)

Soft link and Hard link

soft link - soft link는 original 파일 이름을 가리킨다. original 파일 이름이 바뀌면 soft link는 쓸모가 없게 된다. 다른 파일 시스템의 파일을 가리킬수 있다.
hard link - 파일을 가리킨다.(inode) 원본 이름이 바뀌어도 안깨진다. 다른 파일 시스템을 가리키지는 못한다.

File system mounting

파일 시스템에 새로운 파일 시스템을 붙이는 것.



 

'공부 > 운영체제' 카테고리의 다른 글

Mass-storage structure  (0) 2011.07.13
File System Implementation  (0) 2011.07.13
Virtual Memory  (0) 2011.07.13
8장 Memory-management strategies  (0) 2011.07.10
7장 Deadlock  (0) 2011.07.09


Posted by skyjumps
공부/운영체제2011. 7. 13. 22:34


메모리 활용을 높이는 방법
초기에는 프로세스의 명령어와 데이터가 실행되려면 프로세스 전체가 물리메모리에 있어야 했었다. 
프로세스 사이즈가 커지면서 메모리 활용에 문제가 생겼고, 이를 해결하려는 방법들이 나왔다.

1) Dynamic loading
시작에는 main routine만 메모리에 로드되어, 다른 routine들은 호출될 때만 메모리로 로드된다.
사용되지 않는 루틴들은 메모리로 로드되지 않아서 메모리 활용이 높아진다.
루틴을 로드할 때의 overhead 문제가 있다.

2) Dynamic linking
library의 linking을 load타임때 하지 않고 runtime 때 사용되면 stub가 library를 메모리로 로드하거나 이미 다른 프로세스에서 사용되어서 로드 되었으면 연결을 시켜준다.
여러 프로세스가 한 library를 공유할 수 있다.

3) Overlays
Dynamic loading과 비슷함. 
프로그래머가 overlay driver를 작성하여, overlay driver는 필요할 때 루틴을 메모리로 로드한다.

4) Swapping
메모리에 있던 프로세스를 디스크로 보내는 것.
나중에 다시 필요할 때 디스크로부터 불러온다.
swap하는 데 걸리는 시간은 전송시간이 큰 부분을 차지한다.

Virtual Memory

logical memory를 physical memory로부터 분리
실행중일 때, 메모리에 필요한 건 프로그램의 일부분이다.
그래서 일부분만 메모리에 올린다면  logical memory는 physical memory보다 훨씬 크게 할 수 있다.
프로그래머는 physical memory size를 걱정할 필요가 없다.

Demand Page

Virtual memory 구현하기위해 필요한 것.
Swapping은 전체 프로세스를 디스크로 옮기는 것인 반면
Demand paging은 프로세스를 page 단위로 나누고 필요한 page만 메모리로 옮겨서 처리하는 것.
Lazy swapper라고 불린다.
Pager는 필요한 페이지만 메모리에 불러온다.
page table 참조해서 페이지가 현재 메모리에 없으면 디스크에서 불러온다.
page table의 valid-invalid bit을 이용해서 해당 page가 메모리에 존재하는지 디스크에 존재하는지 알 수 있다.
valid-invalid bit가 0이라면, 메모리에 없을 가능성이 있어서 page fault 인터럽트 발생

page fault handling

page fault에는 2가지 경우가 있다.
OS가 PCB를 참조하여
1) 그 페이지 주소가 정상적인 범위가 아니어서 invalid 였다면 그 프로세스를 종료시킬 것이고
2)  단지 메모리에 없어서 그런거라면 메모리에 올려주고 vaild bit를 1로 바꿔준다. 그리고 다시 인터럽트된 명령어로 돌아가서 실행한다.

비어 있는 frame이 없을 때
메모리에서 안 쓰는 page를 찾아 디스크로 저장한다.

pure demand paging


실제로 그 페이지가 사용될 때까지 메모리에 올리지 않는다.
이 경우에 만약 명령어마다 한 페이지씩 요구하는 프로그램이 있다면
page fault가 많이 발생해서 성능이 엄청 안좋을 것이다.
locality of reference
다행히 프로그램은 메모리에서 일정 범위안에서만 참조하는 경향이 있다.

실제로 초기화할때 몇 개의 page를 미리 올려놓는다고 한다.

하여튼 성능을 높이려면 page fault의 최소화가 중요하다.

Copy-on-Write

fork()함수는 자식 프로세스를 생성한다.
부모의 주소공간을 카피한다.
부모와 동일한 코드를 실행하기 때문에 메모리를 또 할당할 필요없이 공유할 수 있다.
같은 page를 공유하게 된다.
만약 한 page에 쓰기를 한다면 그 page만 카피해서 새로 만들어준다. copy-on-write
수정이 필요한 page만 새로 만듦으로써 효율적인 메모리 사용이 가능하다.

새로운 page가 필요할 때 메모리에 어떻게 할당할 것인가?

Pool

보통 운영체제는 free pages를 담은 pool을 유지한다.
그래서 자식프로세스가 새로운 page가 필요할 때나 프로세스의 stack이나 heap 공간이 더 필요할 때 pool에서 꺼내 할당할 수있도록 한다.  zero-fill-on-demand 기법을 사용하여 할당되기 전에 그 page에 있던 내용을 다 지워준다.

Page Replacement

over-allocating

demand paging을 이용해서 메모리가 수용할 수 있는 양보다 많은 프로세스를 돌릴 수 있게 되었다.
하지만 어느순간 메모리가 수용할 수 있는 양보다 많은 페이지 요구가 일어날 수 있다.
페이지가 메모리에 없어서 page fault를 했는데 free frame이 없을 경우 어떻게 해야 할까?
프로세스를 하나 죽이는 것은 비효율적이다.
page replacement를 한다.

Basic page replacement

1. 디스크에서 필요한 page의 위치를 찾고
2. free frame 찾기
    2.a 있으면 할당
    2.b 메모리에서 희생될 프레임(victim frame)을 선택한다.
    2.c 디스크에 victim frame을 쓰고 page와 frame table을 변경한다.
3. 디스크에서 그 page를 freed frame에 올린다. page와 frame table을 변경한다.
4. user program을 다시 시작한다.

2번의 page 전송이 일어난다. victim page를 디스크에 저장하는 것, 원하는 페이지를 디스크에서 꺼내오는 것.
이걸 줄여볼 수없을까?

Modify bit(or dirty bit)

page가 수정되었으면 modify bit가 1이 된다.
page replacement할 때 modify bit가 0이면
디스크에 쓸 필요가 없다. page 전송이 한번으로 줄게된다.

disk I/O는 시간이 많이 걸린다.
modify bit로는 불충분하다.
disk I/O를 줄일 수 있는 방법이 필요하다. 즉, page fault가 덜 발생하도록 하는 algorithm이 필요하다. 각각의 프로세스에 얼마나 많은 frame을 할당할 것인지(frame-allocation algorithm)와 page replacement가 필요할 때 어떤 frame을 선택할 것인지(page-replacement algorithm)에 대해 효과적인 방법을 찾아야 한다.

Page replacement algorithms

First-In-First-Out(FIFO) algorithm
page가 교체될 때 가장 메모리에 먼저 들어갔던 page가 교체되는 것.

Belady's Anomaly

그 프로세스에 할당된 메모리가 늘어 났는데 page fault가 더 많이 발생하는 현상.

메모리가 늘어났다고 해서 꼭 좋아지는 것은 아님을 알 수 있다. 

Optimal page-replacement algorithm

향후에 참조될 확률이 제일 적은 page가 교체된다.
컴파일러가 도와주면 가능은 하겠지만
reference string을 미리 알아야 하므로 구현하기 어렵다.

Least Recently Used (LRU) algorithm

가장 오래전에 참조되었던 페이지가 교체된다.
프로그램의 지역성(locality) 때문에 효과적인 알고리즘이다. (프로그램이 참조하는 page가 몰려있다. 한번 참조했던 page는 또 참조될 가능성이 크다.)
구현은 어떻게 할까?
CounterStack을 이용한다.
Counter
page table의 entry마다 counter를 가지고 있다.
페이지가 참조될 때 counter에는 참조된 시각을 기록한다.
가장 오래된 시각을 가지고 있는 페이지를 교체한다.
Stack
page number를 가진 스택이 있다.
page가 참조될 때마다, 스택에 있는 그 page number를 맨 위로 올린다. 
가장 아래 있는 page number가 LRU이다.
doubly linked list로 구현하면 성능향상에 도움이 된다.

OPT나 LRU는 Belady's anomaly 현상이 일어나지 않는다.
메모리 할당이 하나 늘어났을 때 들어있는 page number set이 늘어나기 전의 page number set을 포함하기 때문이다.

하지만 Stack이나 Counter방식은 하드웨어 지원이 필요하고, 매번 메모리 참조가 일어날때마다 clock field나 stack을 업데이트해야 하기 때문에 성능이 느려진다. 

LRU Approximation algorithm

많은 시스템이 reference bit 을 이용해 LRU 비슷한 알고리즘을 하드웨어로 지원해준다.

Additional-Reference-Bits Algorithm

각 페이지당 reference-bits로 8bit 를 가지고 있다. 이 8bit는 일정시간간격으로 오른쪽으로 한칸 시프트 된다. 맨 오른쪽 비트는 버려진다.
그 페이지가 참조되면 맨왼쪽 bit를 0에서 1로 바꿔준다.
가장 적게 사용된 page는 page중에 가장 작은 reference-bits를 가지고 있는 페이지다.
일정시간간격이 좁을 수록 LRU에 가까워진다.


Second-Chance Algorithm
 

reference-bit이 한개이다.
FIFO algorithm에 기반을 두었다.
꺼낸 페이지의 reference-bit이 0면 그 페이지가 교체된다.
reference-bit가 1이면, 이번엔 그냥 넘어간다. 대신에 0으로 바꿔주고 맨 뒤로 보낸다.
최악의 경우에는 모든 page의 reference-bit가 1이 될 경우이다. 이 때는 FIFO 알고리즘이 된다.

Counting Algorithm
각각의 페이지 참조수를 센다.

LFU (Least Frequently Used) Algorithm
가장 작은 count를 가진 page를 교체한다.
하지만 그 페이지가 초기에만 엄청 사용되고 그 뒤에는 전혀 사용되지 않는다면?

MFU (Most Frequently Used) Algorithm
가장 큰 count를 가진 페이지를 교체한다.
작은 count를 가진 page들이 아직 할 일이 있을 것이다라는 생각에.


Allocation of Frames
 

각각의 프로세스는 최소로 필요한 page수가 있어야 한다.
첫번째 이유는 performance 때문. 할당된 frame 수가 줄어들수록 page fault가 자주 발생하게 된다. 그리고 page fault가 발생하면 처리된 후에 실행중이었던 명령어가 다시 실행되어야 한다. 그래서 최소한 page fault 없이 한 명령어를 실행할 수 있는 프레임이 할당되어야 한다.
프로세스당 최소 프레임 수는 architecture에 의해 정해지고, 최대 프레임 수는 이용가능한 물리 메모리에 의해 정해진다.

할당 알고리즘
 

1. equal allocation
100개 frame과 5개 프로세스가 있으면 한 프로세스에게 20개씩 똑같이 주는 것.
2. proportional allocation
프로세스 사이즈에 비례하여 frame을 준다.
3. priority allocation
프로세스 우선순위에 비례하여 frame을 준다. 아니면 우선순위랑 사이즈 모두 고려해서 줄 수도 있고.

global vs. local allocation
 

여러개의 프로세스가 프레임들을 차지하고 있는 상황에서
페이지 교체할 때
global replacement은 모든 프레임에서 교체할 프레임을 선택하는 것.
local replacement은 자기 프로세스에서 교체할 프레임을 선택하는 것이다.
global replacement의 한가지 문제는 자신의 page-fault rate를 조절 할 수 없다는 점. 왜냐하면 자신의 paging 방식뿐만 아니라 다른 프로세스의 paging 방식에 영향을 받기 때문. 따라서 같은 프로세스의 수행시간이 때에 따라 다르게 나올 수 있다.
local allocation은 한 프로세스가 자신에게 할당된 pages를 잘 활용하지 못할 때, 다른 프로세스가 페이지를 얻는 것을 방해하는 셈이 된다. 그래서 global replacement가 시스템 처리율에 있어서 더 좋아서 더 많이 쓴다.

Thrashing
 

낮은 우선순위를 가진 프로세스의 프레임이 컴퓨터아키텍쳐에가 요구하는 최소 프레임수 아래로 떨어지면 그 프로세스가 가진 남아있는 페이지들을 디스크에 저장하고 (Swapped out) 할당된 프레임을 해제시켜야 한다.
충분한 프레임을 갖지 못한 프로세스는 page fault가 발생할 가능성이 높다.
process가 thrashing 하다는 것은 프로세스가 실행하는 것보다 paging에 더 많은 시간을 쓸 때를 말한다.

Thrashing이면 CPU utilization이 떨어진다.
Global replacement일 때, 프로세스가 다른 프로세스 프레임 뺏고, 다른 프로세스가 그 프레임 읽으려고 했는데 없어졌으니까 또 다른 프로세스 프레임 뺏고 하는 상황이 생길 수 있다. paging 해주는 장치가 바빠져서 프로세스들은 waiting 큐 대기해서 paging 장치를 사용하기를 오랫동안 기다려야 한다. waiting큐에 쌓일 수록 ready 큐에는 아무것도 없는 상황 발생. 그래서 CPU 활용률은 떨어지게 되는 셈.
CPU 스케쥴러가 cpu utilization이 떨어지는 것을 보고 멀티프로그래밍정도를 증가시킨다. 그러면 상황이 더 악화.
처리되는 프로세스 수가 많아질 수록 CPU utilization은 올라가다가 어느 순간 떨어진다. 이때가 Thrashing 상태이다.
Thrashing을 막기 위해서는 멀티프로그래밍 정도를 낮춰야 한다.
local replacement 알고리즘을 사용한다면 막을 수 있을까? 이 알고리즘 쓰면 한 프로세스가 thrashing 하더라도 다른 프로세스의 프레임을 뺏지 못할텐데..
그래도 완전한 해결책이 되지 못한다. 프로세스들이 thrashing에 빠지면, paging device를 위한 큐에서 대기하는 시간이 길어질거고 page fault 처리하는 시간도 길어진다. 그 결과 thrashing이 아닌 다른 프로세스들에 접근하는 시간도 길어지게 된다.

Thrashing을 막기위해서는 가능한 많은 프레임을 프로세스에게 주어야 한다. 하지만 얼마나 많은 프레임이 필요한지 어떻게 알까?
Working-set strategy방법을 쓴다. 이 방법은 프로세스 수행이 locality하게 된다는 것이 전제로 한다.
Locality model은 프로세스가 수행될 때 한 지역에서 다른지역으로 움직인다는 것이다. 한 지역은 함께 자주 사용되는 페이지들의 영역이다. 한 프로그램은 몇개의 localities가 있다.
Locality model에 의해 Thrashing을 해결하려면 한 프로세스에게 최소한 현재의 locality를 수용할 수 있는만큼 frame을 할당한다.

Working-set model
locality에 기반한 방법.
Δ : working-set window, 일정한 갯수의 페이지를 담는 창. 
창에 참조되는 새로운 page 번호가 계속 들어오고, 창 범위를 넘어간 오래된 page는 나간다.
윈도우 사이즈가 너무 작으면 locality를 반영할 수 없고, 클 수록 일부 locality를 반영할 수 있다. 창 사이즈가 무한대면 모든 locality 반영.
working set :가장 최근의 Δ에 있는 페이지들 집합.
한 프로세스의 working set의 크기를 D라고 하면 D는 그 프로세스가 필요한 프레임의 크기이다.

D가 현재 이용가능한 프레임보다 크면 Thrashing이고, 이 때는 페이지를 확보하기 위해 돌아가고 있는 프로세스 중에 하나를 중지시켜야 한다. 그래서 최소한 D만큼의 프레임은 있도록 한다.

D가 계속 변하기 때문에 메모리 할당 크기는 시간에 따라 달라지게 된다.

매번 참조되는 페이지랑 working-set이랑 비교하는 것은 비용이 많이 든다.
따라서 대략적인 방법을 이용한다.
일정 시간마다 타이머 인터럽트를 발생시킨다. 그래서 그 때의 Δ를 이용한다.
각각의 페이지마다 2bit의 과거의 참조 정보를 가지고 있다.
2bit의 과거참조정보는 인터럽트가 발생하면 왼쪽 시프트해서 오른쪽 bit가 0이 되고 
Δ에 해당 페이지가 있으면 그 페이지의 오른쪽 bit에 1을 넣는다.
2bit 중에 어느 하나라도 1이면 page는 working-set에 포함된다.
일정 시간 내에서 정확한 참조 발생 위치, 시간을 알 수 없기 때문에 정확하지는 않다.
과거정보를 기억하는 bit를 늘려주고 타이머 인터럽트 시간을 더 주기적으로 해주면 더 정확해지지만 비용이 많이 든다.
 
Page-fault frequency방법
한 프로세스의 page-fault 비율을 모니터링
page-fault 비율이 너무 높으면 프레임을 더 주고, 너무 낮으면 프레임을 뺏는다.


Memory Mapped Files
virtual address를 이용해서 file i/o를 메모리 접근 루틴으로 하는 방법.
파일을 메모리로 읽어와서 read(), write() 대신에 virtual address를 호출하는 방식으로 파일처리.

디스크에 있는 파일이랑 동기화가 바로 안된다.
close()하면 memomy-mapped data가 disk에 쓰여지고 virtual memory로부터 제거된다.

여러 프로세스가 같은 mapped 된 파일을 동시에 접근할 수 있다.
copy-on-write기능을 지원해야.
여러 프로셋가 쓸 경우 동기화문제도 다루어야 한다. 

Memory Mapped I/O
더 편리하게 I/O장치에 접근하기 위해 많은 컴퓨터아키텍쳐들은 memory mapped i/o를 제공한다.
각각의 I/O 컨트롤러는 CPU로부터 전송된 명령이나 데이터를 저장하는 레지스터를 가지고 있다.
이 레지스터들을 메모리로 매핑한다. 따라서 메모리 주소로 레지스터 값을 읽고 쓸 수 있다.
device register는 I/O port라고 불린다.
CPU는 이 I/O port를 통해 데이터를 전송하고 받는데,  
CPU가 memory mapped 된 i/o port로 데이터를 보내고 control register에 데이터 보냈다고 bit을 입력하면
device는 그 데이터(byte)를 받고 다음 데이터 보내라고 control register의 그 bit을 clear한다.
Programmed I/O 
CPU가 control register의 그 bit를 계속 감시하고 있는 것. device가 준비가 되었나 안되었나 계속 주시.
interrupt driven
CPU가 bit 감시안하고 그 시간에 다른 일하다가 인터럽트로 보고 받는 것.

중간정리
page management 큰그림

출처 : http://oslab.snu.ac.kr/course/2010_fall/os/lecture_note/2010-os-ch10nn.pdf

다른 고려사항들
Preparing
많이 참조될 만한 것을 미리 한번에 메모리로 다 가져온다.
pure demanding-paging은 시작할 때 많은 page fault 발생
프로세스가 중지되었을 때 working-set을 저장했다가 다시 시작할 때 working set을 불러오는 방법.

Page size selection
page size가 작으면 i/o 시간이 적게들고, internal fragmentation이 적다. page table size는 커진다.(table fragmentaion 문제)
page size가 크면 page fault 빈도가 줄어든다. 

TLB Reach
TLB의 hit-rate는 엔트리 수하고 관련되어 있다.
hit-rate를 높이려면 엔트리 수를 키워야 하는데, TLB를 구성하는데 이용되는 메모리가 비싸다.

hit-rate와 비슷한 평가요소인 TLB Reach
TLB로부터 접근할 수 있는 메모리 양(앤트리 수 * 페이지 사이즈)
성능이 가장 좋은 이상적인경우는 working set을 모두 cover할 수 있을 정도의 TLB Reach가 되는 것.
TLB Reach 크기를 늘일 수 있는 경우는 두가지.
page size가 크게 또는 다양한 size의 page를 제공
페이지 크기 크게 하면 in fragmentation이 생길 수 있다.
페이지 사이즈를 다양하게 하면 OS가 TLB를 관리 해야 한다.

I/O Interlock
메모리에서 쫓겨나면 안되는 페이지들을 locked한다.

Consider I/O
디바이스에서 파일을 카피하는데 이용되는 페이지들은 page replacement algorithm에 의해 선택되면 안된다.locked한다. 

'공부 > 운영체제' 카테고리의 다른 글

File System Implementation  (0) 2011.07.13
File System  (0) 2011.07.13
8장 Memory-management strategies  (0) 2011.07.10
7장 Deadlock  (0) 2011.07.09
6장 Synchronization  (0) 2011.07.04


Posted by skyjumps
공부/운영체제2011. 7. 10. 11:09


Background
CPU는 메인메모리와 레지스터를 통해 명령어와 데이터를 가져온다.
레지스터의 경우엔 한사이클에 가져올 수 있지만 메모리에서 데이터를 가져오려면 여러 사이클이 필요하다.
이 둘의 속도차이를 줄이기 위해 캐쉬가 있다.

각각의 프로세스는 분리된 메모리 공간에 저장된다.
base register와 limit register를 이용해 다른 프로세스 영역에 침입하지 못하게 한다.
이 두 레지스터는 커널이 관리하고 유저모드에서는 변경을 할 수 없다.

Address binding
메모리 주소를 결정할 때 대개 다음과 같은 과정을 거친다.
프로그램 소스는 변수를 이용해 값에 접근 할 수 있다.(symbolic address) 컴파일러를 통해서 이 symbolic address는 relocatable address로 바뀐다. '예를 들면 모듈로 부터 14byte 떨어진 위치에 있다.' 이런식이다. 그리고 linkage editor와 loader는 relocatable address를 absolute address로 바꾼다.

하지만 항상 이 모든 단계를 거치지는 않는다. compile 시간에 메모리 어디에 프로그램이 올라갈 것인지 알수 있다. 하지만 나중에 시작 위치가 바뀌게 되면 재컴파일 해야 된다. 또 다른 경우로 컴파일 시간에 알지 못하면 컴파일러에 의해 relocatable code가 생성되고 메모리로 올라가는 load 시간에 주소가 결정이 된다. 이 때는 시작 위치가 바뀌게 되더라도 변경 된 값을 적용 시켜주면 된다. 그리고 실행 시간에도 프로세스가 변동가능성이 있을 수 있다. 실행 중에 주소가 결정되게 된다.

Logical vs. Physical Address Space
Logical(virtual) address는 cpu가 생성하는 주소이다.
그리고 Physical address는 메모리가 인식하는 주소이다.
실행 중에 주소가 결정될 경우, Virtual address를 Physical address로 바꿔주는 시스템이 필요하다.
이를 memory-management unit( MMU)가 이 일을 한다. CPU가 logical address를 사용하면 MMU의 relocation register가 메모리에 접근할 수 있는 physical address로 바꿔준다.

Dynamic loading
메모리 공간 활용을 잘 하기 위해 사용. 루틴이 실제 호출 될 때까지 디스크에 있는다. 사용될 때, relocatable linking loader가 호출되어 디스크에 있던 루틴을 메모리로 불러들이고 프로그램 주소 테이블을 수정한다.
사용되지 않는 루틴은 절대 호출되지 않아 메모리 공간을 아낄 수 있는 장점이 있다.

Dynamic linking and Shared Libraries
대개 system library에 사용된다.  각 프로그램마다 실행가능한 이미지 만들 때 library가 복사되어 들어간다면 디스크와 메모리 공간을 낭비하는 셈.
stub가 실행가능한 이미지에 library 대신 들어가서 library가 필요할 때, library가 메모리에 없다면 메모리에 불러와주고, 이미 있다면 연결시켜준다. stub는 이러한 일을 할 줄 아는 코드다.
이러한 dynamic linking(실행중 연결)을 통해 프로세스들은 각자의 library를 가질 필요가 없이 library를 공유할 수 있게 된다.
 
Contiguous Allocation
각각의 프로세스가 메모리에서 하나의 연속적인 공간으로 할당되는 것. 

Memory Mapping and Protection
limit register와 relocation register를 이용해서 메모리 매핑과 보호를 한다.
limit register는 logical address의 범위값이고, relocation register는 가장 작은 물리 주소를 가진다.
logical address는 반드시 limit register보다 작아야 한다.
MMU는 relocation register를 통해 동적으로 물리주소로 매핑할 수 있다.

Dynamic Storage-Allocation Problem
여러개 프로세스가 메모리 할당되고 해제되고 하다보면 프로세스 사이에 메모리 공간이 있게 되고 그 공간이 크면 새로운 프로세스를 그 공간에 할당할 수 있다. 작은 공간은 못쓰고 빈 상태로 있다. 운영체제는 할당된 공간과 할당되지 않은 공간에 대한 정보를 가지고 있어야 한다.
빈공간을 활용하여 프로세스를 넣는 방법은 세가지 있다. First-fit, Best-fit, Worst-fit.
First-fit은 처음 발견한 공간이 프로세스를 넣을 만큼 충분하다면 다른 빈공간 안보고 거기다가 넣고
Best-fit은 최대한 아낄려고 모든 빈공간을 다 본 후 가장 알맞은 빈공간에다가 넣고
Worst-fit은 모든 빈공간을 다 보고 가장 큰 공간에다가 넣는 것이다.

Fragmentation
프로세스가 메모리에 계속 들어갔다 나왔다하다 보면 빈공간이 너무 작아 어떤 프로세스라도 들어갈 수 없는 것들이 많이 생기게 된다. 이걸 External Fragmentation이라 하고
Internal Fragmentation은 요청한것보다 약간 크게 할당될 수도 있는데 일부분을 안쓰게 되는 현상이다.
그래서 압축을 하자니 실행중인 프로세스들을 일시중지해야 되므로 현실적으로 어렵다. 그래서 나오게 된것이 Page와 Segmentation 개념이다.

Paging
프로세스가 메모리에 연속적으로 저장되지 않아도 된다. 쪼개져서 저장될 수 있다.
paging의 기본방식은 물리주소공간을 frame단위로 쪼개고, 논리주소공간을 frame과 같은 사이즈로 쪼갠다. 논리주소공간의 쪼개진 조각들은 page라고 한다.
메모리 할당이 고정된(page, frame)단위로 이루어 지므로 external fragmentation이 없다. Internal은 마지막 프레임에서 발생할 수 있다.
대신에 주소 변환과정이 좀 복잡해진다.
page가 어느 frame인지 알려주는 page table이 있어야 한다. 프로세스별로 하나씩 있다.
하드웨어가 페이지방식을 지원. -> CPU가 주소를 생성할 때, page number와 page offset으로 나눠서 생성한다. page number로 frame의 시작 위치를 찾고, offset과 시작 위치를 합쳐서 정확한 메모리 주소를 알수 있다.

페이지 테이블은 레지스터에 저장하면 빠르겠지만 요즘 컴퓨터는 페이지개수가 많기 때문에 메모리에 저장한다. (PCB)
하드웨어는 Page-table base register(PTBR)를 제공해서, 페이지테이블이 빨리 바뀔 수 있게 도와준다.
페이지 테이블 참조하느라 한 바이트 읽는데 메모리를 2번 참조하게 된다. 문제다.
하드웨어는 이 문제에 대해 Translation Look-Aside Buffer(TLB)라는 작은 캐쉬를 제공한다.
TLB에 페이지정보가 있으면 메모리에서 읽어오는 것보다 빨리 물리메모리 주소값을 얻을 수 있다.

Protection
page 환경일 경우 memory protection은 각 프레임의 protection bit를 붙여서 수행한다. bit값들은 page table에 저장된다.
이 bit를 이용해서  vaild/invalid를 설정한다. vaild이면 이 페이지가 프로세스의 logical address임을 의미한다. 따라서 사용하지 않는 logical address일 경우엔 invalid로 설정되어 잘못된 메모리에 접근 하는 것을 막아준다.
대개 많은 프로그램들이 자신에게 할당된 logical address를 다 사용하지 않는다. 그래서 모든 logical address를 포함하는 page table은 공간 낭비가 심하다. 그래서 몇몇 시스템은 하드웨어가 page-table length register(PTLR)을 제공하여 페이지 사이즈를 정하게 된다.

Shared Pages
프로세스들이 공통된 page를 따로 메모리에 로드 시킬 필요없이 서로 공유할 수 있다.
page를 read만 할 거면 공유해도 문제없다.(프로세스의 code부분)

Structure of the Page Table
32bit 주소 공간이면, 
페이지 테이블 사이즈게 엄청 커지게 된다.
페이지 크기가 4KB(2^12)이면 페이지 테이블의 엔트리 수는 2^32/2^12 = 2^20 이고 엔트리 하나당 크기가 4byte면 페이지 엔트리 크기는 4MB. 페이지테이블 사이즈가 크면 메인메모리에 한번에 담기 어렵다.

Hierachical Paging
페이지 테이블을 몇단계로 나눈다. 계층화한다.
outer page table들을 통해 page table에서 물리주소를 알아낸다. 

Hashed Page Tables
주소공간이 32bit보다 클 경우 대개 hash를 사용한다.
논리 주소의 페이지숫자를 hash function에 넣어 나온 해쉬값으로 물리 주소공간의 프레임 위치를 알아낸다.

Inverted Page table
프로세스마다 페이지 테이블이 하나씩 있을 경우, 하나의 페이지 테이블은 자신이 사용하는 물리 메모리 이외에도 사용하지 않는 물리 메모리 정보도 가지고 있으므로 많은 공간을 차지할 수 있다. 이런 문제를 해결하는 방법으로 프레임(실제메모리)을 엔트리로 가지고 있는 페이지 테이블을 사용할 수 있다. 테이블이 하나면 된다. 테이블의 하나의 엔트리에는 <process-id, page-number, offset>으로 이뤄져 있어 cpu가 logical address <pid, p, d>를 보내면 이 페이지 table에서 맞는 <pid, p>를 찾고 이 엔트리는 physical address로 정렬되어 있기 때문에 테이블에서의 위치값이 frame의 번호가 된다.
좋은점은 테이블이 하나면 된다느 것이고 문제점은 찾는데 너무 오래 걸린다는 것이다. 그리고 shared page 구현이 어렵다.

Segmentation
유저 관점에서 본 메모리 매핑 기법.
프로그램을 segment들의 집합으로 본다.
segment는 함수, 스택, symbol table(변수이름, 함수이름) 등 사용자가 프로그램을 봤을 때 나눠지는 것들이다.
paging과 구현방식이 비슷하다.
Logical address는 <segment-number, offset>으로 표현되고
Segment table이 있다. table entry에는 base와 limit가 있다. base를 통해 physical 메모리의 어디에 놓일지 알 수 있고, limit를 통해 segment의 사이즈를 알 수 있다. 메모리에 segment별로 저장이 되며, segment끼리 침범하지 않도록 보호할 수도 있고, 프로그램끼리도 보호할 수 있고, code나 data를 공유할 수도 있고, 다른 프로그램이 segment를 공유할 수도 있다. segment가 다양한 사이즈이다 보니 external flagmentation 가능성이 있다.

Segmentation with Paging 
Segmentation과 paging을 둘다 이용한 메모리 매핑 기법.

참고사이트
http://bywords.tistory.com/70 

'공부 > 운영체제' 카테고리의 다른 글

File System  (0) 2011.07.13
Virtual Memory  (0) 2011.07.13
7장 Deadlock  (0) 2011.07.09
6장 Synchronization  (0) 2011.07.04
Process scheduling  (0) 2011.07.03


Posted by skyjumps
공부/운영체제2011. 7. 9. 15:13


blocked 프로세스가 서로 필요로 하는 자원을 가지고 있을 때.

System Model
시스템은 자원(씨피유 사이클, 메모리 공간, I/O 디바이스 등)들로 이루어져 있다. 
각각의 자원은 여러개의 인스턴스가 있다.
프로세스가 한 자원 type의 인스턴스를 요구하면 그 타입의 어떤 인스턴스라도 그 요청을 수행할 수 있다.
자원을 사용하고 나서는 반드시 반환해야 한다.

Deadlock Characterization
네가지 조건이 동시에 발생했을 때 Deadlock이 발생할 수 있다.
1. Mutual exclusion(리소스가 여러 프로세스에 의해 공유될 수 없다.)
2. Hold and wait (하나 이상의 리소스를 가지고 있는 채로 다른 자원을 획득하기를 기다리는 것)
3. No preemption (중간에 리소스를 뺏기지 않는 것. 작업을 마치고 내놓는 것)
4. 기다리는 프로세스들이 사이클을 이룰 때. p0는 p1이 가지고 있는 리소스를 원하고, p1은 p2, p2는 p0.

일반적으로 사이클이 없으면 데드락이 없다. 사이클이 있으면 데드락 가능성이 있다. 하지만 있어도 반드시는 아니다. 하나의 자원 type에 여러개 인스턴스가 있는 경우 데드락이 생기지 않을 수도 있다.

Methods for Handling Deadlocks
시스템이 데드락 상태에 빠지는 것을 허용하지 않도록 하는 것.
시스템이 데드락 상태에 빠지는 것을 허용하나, 그것을 감지하고 회복하는 것.
데드락 상태에 빠지면 그 문제를 무시하고 데드락이 발생하지 않은 것처럼 행동하는 것.

Deadlock Prevention
4가지 데드락 발생 조건 중에 최소한 하나라도 성립하지 않게 하기.
mutual exclusion
read-only 파일은 프로세스 여러개가 동시에 접근해도 상관없다.
하지만 원래 공유가 불가능한 자원들이 있다.

Hold and wait
프로세스가 어떤 자원을 요청하기 전, 아무 자원도 가지지 않은 상태가 되도록 한다.
낮은 자원 이용률, starvation 가능성이 있다.

No preemption
프로세스가 어떤 자원을 요청했으나 받지 못하고 기다려야 한다면 지금 가진 모든 자원을 버리고 wait 상태가 된다.
모든 필요한 자원을 얻었을 때 다시 시작된다.

Circular wait
모든 자원에 순서를 매긴다. 높은 숫자의 자원을 가지고 있는 프로세스가 낮은 숫자의 자원을 가지지 못하도록 한다.

Deadlock Avoidance
어떤 리소스를 할당하고 해제하는지 순서를 안다면, 즉 리소스가 어떻게 요청되는지 추가적인 정보를 안다면
미래에 발생할 수 있는 deadlock문제를 사전에 방지할 수 있다.
가장 간단하고 효과적인 방법은 프로세스가  각 type별 최대로 필요한 리소스의 수를 정하는 것이다.
리소스 할당 상태를 조사하여 circular-wait condition이 발생하는지를 알아본다.
리소스 할당 상태는 이용가능한 자원의 수, 할당된 자원의 수, 프로세스의 최대 요구 자원의 수로 정의된다.

Safe state
데드락을 피하도록 자원을 할당받는 프로세스순서 정하기.
이러한 순서를 safe sequence라고 하고
safe sequence에서 한 프로세스가 요구하는 리소스가 (1)현재 이용가능한 리소스와 (2)이전 순서의 프로세스가 가진 리소스의 합보다 작으면 그 프로세스는 요구하는 리소스를 모두 받을 수 있음을 의미한다. 이전 순서의 프로세스는 작업이 끝난뒤 리소스를 반환할 것이기 때문이다.

시스템이 safe state에 있으면 데드락이 발생하지 않을 것이고, unsafe state에 있으면 데드락 가능성이 있지만 반드시 발생하지는 않는다.
따라서 Deadlock Avoidance는 시스템을 항상 safe state한 상태로 유지시키는 것이다.

Resource-Allocation Graph Algorithm
리소스와 프로세스의 관계를 그래프로 표현.

출처 : vidyaprasar.dei.ac.in

점선은 프로세스가 자원을 요청한 상태이다.
할당할 때 cycle이 되는지 조사한다.

Banker's Algorithm
각 리소스 타입마다 인스턴스가 여러개 일때의 알고리즘.
1. 각 프로세스는 각 리소스 타입별로 최대 필요한 인스턴스 수를 가지고 있어야 한다.
2. 이 숫자는 시스템의 전체 자원의 수를 넘지 않아야 한다.
3. 프로세스가 리소스들을 요청할 때, 시스템은 이 자원 할당이 시스템을 safe state하게 하는지 조사해야 한다.
4. 조사 결과 safe state이면 할당
5. unsafe state이면 다른 프로세스가 자원을 방출할 때까지 기다린다.

Safety Algorithm
모든 프로세스의 현재 필요한 자원을 현재 이용가능한 자원으로 처리할 수 있는지 조사.
Dijktra

Deadlock Detection
시스템이 데드락 prevention이나 avoidance한 알고리즘을 제공하지 않으면 detection이라도 제공해야.
wait-for graph

출처 : academic.udayton.edu
resource allocation graph에서 리소스 타입만 제거한 것.
사이클이 생기는지 조사.

Detection algorithm

모든 프로세스에 대해서 현재 이용가능한 자원으로 요청된 자원을 처리할 수 있는지 조사.
하나라도 처리못하는 프로세스가 있으면 그 프로세스는 데드락에 빠진 것. 다른 프로세스들이 완료해서 충분한 리소스를 반환해서 데드락이 깨질 때까지 대기상태에 들어감.
데드락이 자주 발생하면 자주 detection 알고리즘을 수행해 주어야 한다.

자원 할당 요청이 들어오고 즉시 처리할 수 없는 경우마다 이 알고리즘이 호출 될 수 있다.
성능우려 때문에 한시간마다 한번씩, 또는 CPU 이용률이 40퍼센트 이하로 떨어졌을 때 호출하는 방법이 있다.

Recovery from Deadlock 
모든 deadlock 된 프로세스들을 죽이는 방법 - 많은 비용.
사이클이 제거될 때까지 한번에 한 프로세스만 죽이기 - 하나 죽일때마다 detection 알고리즘 호출해야 되서 성능 저하. 그리고 죽이는 것도 어렵다. 그 프로세스가 파일을 수정중이었다면?
그래서 이 방법을 쓴다면 잘 선택하는 것이 중요. 최소비용을 선택
프로세스 우선순위, 프로세스 진행율, 얼마나 많은 혹은 어떤 타입의 리소스가 사용되었는지, 완료하려면 얼마나 많은 리소스가 필요한지, 얼마나 많은 프로세스가 종료될 것인지,  프로세스가 interactive인지 batch인지.
Recovery의 세가지 이슈
죽일 프로세스 선택, Rollback(현재 실행중인 프로세스들의 상태 정보를 다 기억해줘야 되는지), Starvation(한 프로세스만 자꾸 리소스를 뺏겨서 victim이 될 때) 

'공부 > 운영체제' 카테고리의 다른 글

Virtual Memory  (0) 2011.07.13
8장 Memory-management strategies  (0) 2011.07.10
6장 Synchronization  (0) 2011.07.04
Process scheduling  (0) 2011.07.03
Multithreaded Programming  (0) 2011.06.30


Posted by skyjumps
공부/운영체제2011. 7. 4. 01:07


Background

공유 자원에 동시에 접근하는 것은 data inconsistency(데이터 불일치) 문제를 야기할 수 있다.
bounded buffer 문제는 n개 버퍼에 기껏해야 n-1개 아이템만 들어갈 수 있다.
counter 변수를 사용해서 n개 아이템이 들어갈 수 있도록 해보자.
그러면 counter++, counter-- 가 atomically하게 수행되어야 한다.
atomic operation은 인터럽트없이 명령이 완전히 수행되는 것을 의미한다.
counter++와 counter--는 컴퓨터에서 3개 명령으로 처리한다. (counter에서 레지스터로 값을 읽어오고, 레지스터 값을 1 증가하고, 레지스터 값을 counter변수에 넣기) 따라서 중간에 인터럽트가 되면 counter에 원하지 않는 값이 들어간다.
Race condition
여러 프로세스가 공유자원에 동시에 접근하는 상황
이러한 상황을 막기 위해 프로세스들이 synchronized 되어야 한다.

The Critical-section problem
 
공유 자원을 접근하는 코드부분.
한 프로세스가 critical section 부분을 실행중일 때 다른 프로세스가 공유자원을 접근하지 못하도록 해야 한다.
세가지 요구사항
1. mutual exclusion
한 프로세스가 critical section에서 수행중일때, 다른 프로세스들은 그들의 critical section을 수행할 수 없도록.
2. progress
critical section 밖에서 수행중인 프로세스들은 다른 프로세스가 그들의 critical section으로 들어가는 것을 방해할 수 없다.
3. bounded waiting
한 프로세스가 자신의 critical section에 접근하려고 하는데 다른 프로세스가 계속 사용중이라면 기다리는 시간이 한정되어 있다. 

첫번째 알고리즘
mutual exclusion인데, progress가 아니다. Pi가 critical section에 들어가지 않았는데도 Pj가 한번 더 들어갈 수가 없다.

공유데이터 이외에도 전체 코드를 보호할 수 있는데 이는 성능이 떨어진다.

두번째 알고리즘
mutual exclusion이지만 progress가 아님. 둘다 동시에 손들면 deadlock발생 가능성.

세번째 알고리즘
첫번째, 두번째 알고리즘을 합침. 3개 모두 만족

Bakery Algorithm
프로세스에게 번호표를 나눠준다. 가장 작은 수를 가진 프로세스가 critical section에 들어갈 수 있다.
번호는 항상 증가한다.


Synchronization Hardware

하드웨어로 critical section 문제 처리
critical section 들어갈때 인터럽트 disable, 나올때 enable.

Test and Set
특별한 하드웨어 명령어.
atomically하게 실행

Swap

위 두 알고리즘은 mutual exclusion 요구사항은 만족하지만 , bounded-waiting 요구사항은 만족하지 못한다. 운이 나쁘면 계속 못들어간다.


Semaphores and Mutexes

이전 solution들은 더 복잡한 문제에는 적합하지 않다.
세마포어는 OS에서 지원하고 하드웨어나 소프트웨어적으로 구현할 수 있다.
wait(S) 와 signal(S)함수는 atomic하게 실행된다.
while로 구현한 세마포어의 장점은
반응 속도가 빠르다는 점이고 단점은
while로 인해 cpu time을 낭비한다는 것이다. 이러한 종류의 세마포어를 spinlock이라고 부른다.

busy waiting을 피할 수 있는 세마포어
블락을 이용.
블락된 프로세스들의 리스트가 있다.
프로세스가 critical section을 벗어나면 signal을 통해 리스트에서 하나를 깨워준다.
PCB의 link field를 이용해 쉽게 구현가능.
FIFO 큐를 이용해서 bounded waiting 보장.
하지만 세마포어의 사용은 특정 큐 전략에 의존해서는 안된다.
wait와 signal 함수는 atomic하게 실행되어야 한다.
싱글 프로세서의 경우에는 그 프로세서가 인터럽트 못걸게 막으면 된다.
하지만 멀티 프로세서는 모든 프로세스를 막아야 하니 어렵고 성능이 떨어진다.
while로 구현한 세마포어를 사용할 경우 atomic하게 실행된다.
대개 프로그램을 잘짜면 long waiting이 드물다. 

Deadlocks and Starvation
두개 이상의 프로세스가 이벤트를 무한히 기다릴때, 그 이벤트는 기다리고 있는 프로세스 중의 하나가 생성할 수 있는 것일때. 이러한 상황을 Deadlock.

Starvation
무한 블락킹에 빠질경우. 프로세스가 세마포어에서 무한정 기다리게 된다. 예) 리스트가 LIFO일 때, Starvation의 가능성 있다.

두종류의 세마포어
Counting semaphore
세마포어 값(S)이 1보다 큰 값을 가질 수 있다.
critical section에서 여러개의 프로세스가 동시에 실행가능

Binary semaphore
세마포어 값이 0,1만 가진다.
구현이 쉽고
counting semaphore를 구현할 수 있다.??

Mutex
세마포어의 일종
binary 세마포어
소유권의 개념을 가지고 있음.(lock을 건 task만 unlock을 할 수 있다.)
주로 thread간 동기화에 쓰인다. 

Classical Problems of Synchronization

1. Bounded-Buffer using semaphores.
생산자는 empty 감소, full 증가.
소비자는 empty 증가, full 감소.

2. Readers-Writers Problem
버퍼는 하나이고 리더와 라이터는 여러명 일때 버퍼에 어떻게 access하나?
reader를 존중했을 때
writer가 버퍼 사용을 허락받았으면 readers는 기다림.
다른 리더가 버퍼 사용하고 있어도 리더들은 안기다려도됨.
writer가 unbounded waiting에 빠질 수 있음.

writer를 존중했을 때
writer가 빨리 수행될 수 있도록.
writer가 기다리고 있을 때는 어떤 새로운 reader도 buffer에 접근할 수 없다.
reader가 unbounded waiting에 빠질 수 있음.

둘 다 starvation 문제가 있다.

Dining-Philosophers Problem
하는 일이라곤 생각하고 먹을 줄만 아는 5명의 철학자.
둥그런 탁자에 젓가락이 5개밖에 놓여져 있지 않고
배고프면 양옆에 있는 젓가락 2개를 집어야 먹을 수 있다.
하지만 하나 밖에 못집는 상황이 발생.
deadlock과 starvation이 발생할 가능성이 있다.

젓가락 갯수만큼 세마포어가 있을 경우
5명 동시에 젓가락을 하나 집었을 경우 데드락발생

해결방법
철학자 4명만 테이블에 앉게 하기
양쪽 젓가락이 모두 이용가능할때만 집기
홀수 철학자는 왼쪽 젓가락을 먼저 집고 그다음 오른쪽 젓가락을 집는다. 짝수 철학자는 왼쪽 젓가락을 집고 그다음 오른쪽 젓가락을 집는다.

Condition Variable

 어떤 공유 데이터가 특정 상태에 이를 때까지 자신의 실행을 block하게 해준다.
mutex와 함께 사용된다.
mutex는 공유 데이터의 접근을 제어하고
condition variable은 쓰레드가 어떤 공유데이터가 특정한 상태에 이를때까지 wait하게 한다.
condition variable에 의해 wait된 쓰레드는 다른 쓰레드가 공유 데이터에 접근할 수 있도록 자동으로 mutex를 언락한다.
다른 쓰레드에 의해 호출된 signal에 의해 wait하고 있던 그 쓰레드는 다시 꺠어나 mutex를 lock한다.

Conditional variable을 사용하지 않으면 공유 데이터가 특정한 상태에 이르렀는지 계속 조사해야 하므로 쓰레드낭비다.



참고사이트: http://4ellene.net/tt/961 

'공부 > 운영체제' 카테고리의 다른 글

8장 Memory-management strategies  (0) 2011.07.10
7장 Deadlock  (0) 2011.07.09
Process scheduling  (0) 2011.07.03
Multithreaded Programming  (0) 2011.06.30
Process Concept  (0) 2011.06.28


Posted by skyjumps
공부/운영체제2011. 7. 3. 02:58


CPU Scheduler
상태가 ready인 프로세스큐에서 하나 선택.
스케쥴링 결정은 프로세스가 (1) running에서 waiting으로 바뀔때, (2) running에서 ready로 바뀔 때, (3) waiting에서 ready로 바뀔때, (4) 종료될 때 nonpreemptive(자발적으로 cpu를 내놓는것)하게 발생한다. 다른 경우는 preemptive(cpu를 빼기는 것)이다.

preemptive 스케줄링의 문제점
공유데이터 일관성이 깨질 가능성 (한 프로세스가 data를 업데이트하는 중에 다른 프로세스한테 cpu 뺏기고 그 프로세스가 그 data를 읽으려고 할 때)
커널데이터의 일관성이 깨질 가능성
예) 커널이 I/O queue를 바꾸고 있었다. 다른 프로세스에게 cpu를 뺏겼다.
시스템콜을 호출할때 그것이 완료되기까지 다른 프로세스가 돌아가지 않도록 하거나, I/O block을 하는 방법이 있다.

Dispatcher
스케줄러가 프로세스를 결정하고 cpu에게 넘겨주는 작업
context switching.
user mode로 바꿈. 스케줄러는 커널에서 작동하므로.
user program에서 다시 시작할 곳의 위치로 jumping

어떻게 하는 것이 좋은 스케줄링인지 결정하는 기준
좋은 스케줄링일 수록 CPU가 노는 일 없게 한다.
Throughout - 임의 시간동안 처리가능한 프로세스갯수. 최대화
Turnaround time - 프로세스의 제출부터 종료까지 경과되는 시간. 최소화
waiting time - 프로세스가 레디큐에 머물러 있는 시간. 최소화
response time - 프로세스가 만들어졌을때부터 실행하기까지 걸리는 시간. 최소화.

First-Come, First-Served(FCFS) Scheduling
선착순방식.
프로세스 도착 순서에 따라 성능이 좌우.
CPU burst(설명, 간단하게 요구하는 시피유 시간)가 큰 프로세스가 들어오면 average waiting time이 커짐.

Shortest-Job-First (SJF) Scheduling
CPU burst가 가장 작은 프로세스를 실행하도록 스케줄링
2가지 방식이 있다.
nonpreemptive - process에게 한번 cpu가 주어지면 cpu burst가 완료될때까지 cpu를 뺏기지 않는다.
preemptive - 새로운 프로세스가 현재 실행중인 프로세스의 남아있는 burst time보다 작은 burst time를 가지고 있다면 cpu를 빼았는다.

Priority scheduling
우선순위에 따라 CPU를 주는 것.
Preemptive, nonpreemptive가 있다.
SJF도 우선순위 스케줄링 방식(cpu burst time이 작을수록 우선순위가 높은것)이니 위에 것이 이해가 될 듯.
문제점
Starvation - 낮은 우선순위는 영원히 실행 안될 가능성이 있다.
해결책 - aging. 프로세스의 우선순위를 시간이 지나면 올려준다. 나이먹는 것처럼.

Round Robin (RR)
각 프로세스가 작은 단위의 CPU time을 얻는다.
한 프로세스가 cpu 사용시간이 지나면 그 프로세스는 preempted 되고 레디큐의 끝에 추가된다.
보통 average turnaround time은 SJF보다 길지만, response time은 짧다. interaction이 중요한 프로그램에게는 이 방식이 좋을수도.

Multilevel queue
레디큐는 여러개의 큐로 나눠진다.
예) foreground용, background용
각각의 큐는 스케줄링 알고리즘을 가지고 있다.
예) foreground(RR), background(FCFS)
큐들 사이에도 스케쥴링이 있다.
예) fixed priority scheduling(foreground queue의 우선순위가 background queue의 우선순위보다 높아서 높은 우선순위의 프로세스가 무조건 cpu를 뺏어올 수 있도록), Time slice(각각의 큐마다 CPU time을 할당한다. foreground에는 80%, background에는 20% 이런식으로) 

Multilevel Feedback Queue
프로세스가 큐들 사이를 이동 할 수 있는 것.
한 프로세스가 CPU를 너무 많이 잡아먹었다싶으면 낮은 우선순위 큐로 내려보내는 것.

리눅스에서의 스케줄링 정책
출처 : http://kldp.org/node/18841
SCHED_OTHER
: 일반적인 process/thread 의 정책. priority를 0만 가질 수 있음. timeshared.

SCHED_FIFO
: realtime을 위한 정책. priority 1~99. timeshared 아님. 오직 더 높은 priority를 가진 task에게만 선점됨. block, yield, terminate되기 전까지 계속 실행.

SCHED_RR
: realtime을 위한 정책. priority 1~99. 동일한 priority를 가진 waiting SCHED_RR task와 timeshared. timeshare할 대상이 없을 때 SCHED_FIFO와 동일하게 동작.
 

'공부 > 운영체제' 카테고리의 다른 글

7장 Deadlock  (0) 2011.07.09
6장 Synchronization  (0) 2011.07.04
Multithreaded Programming  (0) 2011.06.30
Process Concept  (0) 2011.06.28
2장 System Structures  (0) 2011.06.25


Posted by skyjumps
공부/운영체제2011. 6. 30. 16:27


Threads란?
CPU 이용의 기본 단위. 스케쥴링의 가장 작은 단위
lightweight process라고 부른다.
코드섹션, 데이터섹션, open files나 signal같은 운영체제 자원을 같은프로세스에 속한 쓰레드들끼리 공유한다.
쓰레드끼리 공유 안하는 것은 Thread Id, stack, register, pc 이다.

참고> 코드영역, 데이터영역, 스택영역, 힙영역
코드영역 : 실행할 프로그램 소스코드
데이터영역 : 전역변수, static 변수
스택영역 : 지역변수, 매개변수, 리턴값
힙영역 : malloc같이 사용자가 할당한 메모리가 여기 저장됨.
참고 사이트 : http://blog.naver.com/PostView.nhn?blogId=ace7min&logNo=18253266

장점
1. 쓰레드 중에 하나가 blocking될 경우 다른 쓰레드가 돌아가기 때문에 프로그램이 계속 돌아간다.
2. 메모리와 자원을 공유한다.
3. 같은 프로세스 내에서 쓰레드 전환이 일어날 경우 프로세스 생성을 하지 않고 context switch overhead 작다.

User threads와 Kernel Threads
1) User threads
user-level의 thread library에 의해 관리된다.
커널로부터 지원이 없다.
장점
쓰레드간 전환할 때 커널 스케쥴러를 호출할 필요가 없기 때문에 빠르다. 커널 스케쥴러를 호출함은 유저모드에서 커널모드로 들어가는 것을 의미한다. 이는 레지스터 교환 등 많은 작업이 일어나게 되므로 느려진다.
단점
한 쓰레드가 system call등을 호출해서 커널로 진입할 때 그 프로세스의 다른 쓰레드도 모두 정지된다. 커널이 쓰레드의 존재를 알지 못하기 때문이다. 

2) Kernel threads
커널에서 사용하는 쓰레드.
장점
쓰레드 단위로 스케쥴링이 되므로 멀티프로세서를 활용할 수 있다.
단점
kernel level에서 동작하기 때문에, user level 쓰레드보다 느리다.

Multithreading Models
1) M-to-one
커널쓰레드 하나에 많은 유저쓰레드
쓰레드 하나가 blocking 당하면 나머지 쓰레드도 blocking.
한번에 한 유저쓰레드만 커널쓰레드에 접근 가능하다.

2) One-to-one
커널쓰레드 하나에 유저쓰레드 하나.
멀티프로세서에 병렬적으로 처리가 가능하다.
커널쓰레드를 만드는데 드는 오버헤드는 프로그램의 성능에 안좋은 영향을 줄 수 있다.

3) Many-to-Many
많은 커널쓰레드에 많은 유저쓰레드가 매핑됨.

참고사이트 : http://kldp.org/node/295/  유명한 곳인 듯
 
1. Thread Issue
한 쓰레드에서 fork 호출 할때, 새로운 프로세스는 부모의 모든 쓰레드를 복사할 것인가, 그 쓰레드 하나만 복사할 것인가?
exec()가 바로 호출되면 모든 쓰레드 복사가 필요없을 것이고 exec()가 바로 호출되지 않으면 필요할 것이다.

2. Thread Issue - signal
Unix 시스템에서 사용되고 프로세스에게 특정한 이벤트가 발생했다고 통보한다.
signal 처리
Default action
프로세스가 시그널처리 핸들러가 없을 경우 커널에 의해 처리
core dump(메모리, 레지스터 값을 알려주고) 종료되는 경우 (Abort), 그냥 종료되는 경우(exit), 무시하는 경우(ignore), 프로세스를 정지하는 경우(stop), 정지되었을 경우 재개하는 경우(continue)가 있다.

시그널 핸들러가 있는 경우
스그널을 받으면 핸들러에 따라 처리.
신호를 블락할 수 있다.
그러나 SIGKILL이나 SIGSTOP은 핸들러 처리나 블락 못하고 받아들어야 한다.

한 프로세스에 쓰레드가 여러개 있을 경우 시그널이 어디로 전달되어야 하나 ?
1. 시그널이 적용되는 스레드에게 전달(예 : 동기적 시그널)
2. 모든 스레드에게 전달 (예 : ctrl-c)
3. 프로세스의 특정 스레드에게 전달. 어떤 스레드는 block할 수 있고 어떤 스레드는 accept할 수 있다.
4. 모든 시그널을 받는 지정된 스레드에게 전달.

3. Threading issues - Thread Pool
프로세스 시작시에 쓰레드 미리 생성해서 pool에다가 보관하다가
프로세스가 요청하면 전달한다.
쓰레드가 종료되면 다시 pool로 복귀.
미리 생성해놔서 더 빠르다.
쓰레드 수 제한이 가능해진다. 많은 수의 쓰레드를 동시에 처리하지 못하는 시스템에게는 좋겠지.

4. Threading Issues - Stack overflow
User thread의 스택이 overflow가 날 경우 커널은 알지 못한다.
커널이 protection fault를 감지하고 SIGGEGV 시그널을 해당 프로세스에게 보낸다. 

'공부 > 운영체제' 카테고리의 다른 글

6장 Synchronization  (0) 2011.07.04
Process scheduling  (0) 2011.07.03
Process Concept  (0) 2011.06.28
2장 System Structures  (0) 2011.06.25
1장 Introduction  (0) 2011.06.24


Posted by skyjumps