- Memory 관리 기법 종류
Memory 관리 기법 종류
Fixed Partitioning
균등 고정 분할 방식
실행 이전에 Memory를 동등한 크기의 Partition으로 쪼개서 Program마다 Partition 단위로 할당
장점
- 단순함
- 아무 Partition에나 할당하면 됨
단점
- Internal Fragmentation (내부 단편) 발생 가능 => Partition 내에 비어 있는 공간이 생기는 것
- Active 가능한 Process 수가 정해져 있음
- Partition보다 큰 Process는 실행 불가 => overlay나 swap과 함께 사용해서 해결하고자 함
Overlay
Program의 명령어와 Data들을 Module로 나누어서 먼저 실행되어야 하는 Module을 Memory에 우선적으로 할당했다가, 다음 모듈을 실행할 때 이전 Module을 Swap 해서 Memory를 관리하는 기법
비균등 고정 분할 방식
General 하게 사용불가
미리 Process가 얼마나 사용할 건지 안다면 그나마 괜찮음 => But 근본적인 문제 해결 X
할당 방법
사용 가능하면서 Process가 실행 가능한 공간 중 가장 작은 공간을 줌 => Single Queue
딱 맞는 공간에 할당해서, 자리가 생길 때까지 기다리게 함 => Multi Queue
Dynamic Partitioning
RunTime에서 필요에 따라 동적 할당 => 실행 시에 Partition 분할
Partition 내의 Fragment는 없으나, Partition간 Fragment가 발생 => External Fragmentation (외부 단편화) => Memory Compaction(메모리 압축)으로 메모리를 움직여서 개선
Partition 할당 방법
First-Fit
처음 위치부터, 빈공간들을 탐색하다가 할당할 수 있으면 할당
Next-Fit
마지막으로 할당된 곳부터 빈공간 탐색하다 할당할 수 있으면 할당
Best-Fit
할당 가능한 주소들 중 가장 Fit한 곳에 할당
+ ##### Worst-Fit 가장 차이가 큰 곳에 할당 Partition을 최대한 재활용해서 Compaction을 늦춰보려는 것 +#### 장점 + Internal Fragmentation해결 + 효율적인 Memory 사용Weakness
- External Fragmentation
- Compaction을 위한 Overhead 발생
Buddy System
Fixed Partitioning과 Dynamic Partitioning을 Hybrid 한 것
Buddy Allocation
가용 메모리 영역을 가지고 있다가 요청이 오면 2^k 꼴의 가장 Fit한 Memory Block을 줌
만약 Fit하지 않으면 계속 절반씩 쪼개가면서 찾고, 이 때 Split된 Block을 Buddy라고 함
Block의 크기가 2^k 꼴로 정해져 있다는 점에서 Fixed Partitioning과 유사하지만, Fit한 메모리 크기를 찾는다는 점에서 Dynamic Partitioning과 비슷
만약 쓰고 나서 반환했는데, 동일한 크기의 사용 가능한 Block이 존재하면 Merge함
Slap Allocator
물리적으로 할당된 공간에 미리 다양한 사이즈의 캐시를 해둔다던가 여러개의 오브젝트를 빠르게 할당해둘 수 있다던가 Buddy시스템은 Internal Fragmentation이 필연적으로 나타나지만, Slap은 그걸 줄이고 메모리의 요청 처리 속도가 빠르다 보완 필요
Paging
분산 적재
Page
고정된 사이즈의 조각 단위
프로세스를 조각으로 나눈 것
Segmentation
가변 길이의 조각
Frame
메모리를 조각으로 나눈 것
프로세스가 불연속적으로 배치됨 => 시작 주소만으로는 정확한 위치를 알 수가 없음
=> 순서쌍을 Mapping 해야 함 => Page Table or Page Mapping Table 자료구조 사용하며 순서대로 앞에서부터, 몇번째 Frame Number에 존재하는지가 저장됨
장점
- 오직 Process의 마지막 Page에서만 내부 단편화 생김 (프로세스를 page 크기로 나누어서 적재하므로)
- 외부 단편화 없음
단점
- PageTable로 인해 공간적, 시간적 오버헤드가 발생
Address Translation
기존의 Base, Bound를 통한 계산의 문제점
이전까지는 Logical한 주소를 Physical한 주소로 바꿀 때, Base 주소와 Relative한 주소 값을 계산해 접근하면서, Bound를 통해 해당 Process가 접근 가능한 임계점을 알 수 있었지만, 이제 Page로 메모리 적재가 불연속적으로 변하면서, 더 이상 Base와 Bound로는 할 수가 X
새로운 방법
Frame 사이즈를 2의 배수로 한다면, Page Number와 Offset의 결합이 Relative Address와 동일해진다는 것을 이용, Page Number와 Offset으로 표현
ex : ) 0000~9999 까지를 표현할 때, Page 크기를 1024라고 하면 Page는 0 ~ 8까지 존재, 이때 Offset은 0 ~ 1023이 되고 각각 2진법으로 변환하면 Page는 4비트로 모두 표현 가능(3비트는 최대 7임)하고, offset은 10비트로 모두 표현이 가능
만약 1502라는 값이 들어오면 PageNumber은 1이 되고, offset은 478이 됨 => Relative 주소로 바꾸면 0001 (478을 2진수로 변환한 10자리) 로 바뀌게 됨
계산하는 법
2진수의 논리적인 주소가 주어졌을 때, Page Number Bit가 n Bit면 왼쪽에서부터 N자리만큼 추출해서 계산 후 Page Table에서 Frame Number를 찾고, Frame Number * 2^(offset 표현하는데 사용되는 비트 수) + offset을 하면 Physical Address가 됨
Segmentation
가변적인 조각으로 Process를 나눠 비연속적으로 할당하는 것
Segment Table
각 Segment의 Base와 Limit를 가지고 저장하는 구조
장점
- 내부 단편화 X
- 논리적으로 Segment를 구분하기 때문에, Segment별 Permission을 설정하여 Share나 Protect 하기에 Paging보다 유리
단점
외부 단편화 존재 (만약에 해당 프로세스가 다 끝나서 Release 되고 나서 그 공간이 빔, 가변 길이라 해당 공간을 재활용 하기 어렵고, 그냥 Dummy로 남음)
계산하는 법
Logical 주소가 Sement Number와 Offset으로 구성되고, Segment Number에 해당하는 Segment의 Base 값에 Offset만큼을 더하면 됨
만약 Offset이 Length보다 크다면 불가능
Page와 Sementation 특징
공통점
- Process를 조각으로 나누고, 연속적으로 배치할 필요 X
- Physical Address와 Logical Address가 다르고, 재배치가 가능함
차이점
- Page는 고정된 크기이지만, Segment는 가변 길이의 크기