Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- 정렬
- GIT
- OCR
- typeORM
- 공룡게임
- flask
- nodejs
- Dinosaur
- Nest.js
- Python
- Express
- game
- Bull
- 자료구조
- JavaScript
- cookie
- AWS
- class
- 게임
- react
- jest
- MongoDB
- nestjs
- TypeScript
- dfs
- MySQL
- Sequelize
- mongoose
- Queue
Archives
- Today
- Total
포시코딩
[운영체제] 7. Memory Management (3) 본문
728x90
키워드
paging, segmentation, page table, TLB, two-level page table
Paging, Segmentation 간단 요약
Paging 기법
- 하나의 프로그램을 구성하는 주소 공간을 같은 크기의 페이지로 잘라
페이지 단위로 물리적인 메모리에 올려놓거나 할 수 있다. - 페이징 기법을 사용하면 hole들의 크기가 균열하지 않아 발생하는 문제나,
hole들을 한군데로 밀어넣는 방법을 사용할 필요가 없어진다. - 물리적인 메모리에서 비어있는 위치가 있다는건 페이지 프레임이 비어있는 것이기 때문에
프로그램의 어떤 페이지든지 아무데나 들어갈 수 있기 때문
Segmentation 기법
- 프로그램의 주소 공간을 같은 크기가 아닌 의미 있는 단위로 자르는 방법
때문에 크기가 균일하지 않다. - 프로그램의 주소 공간이 code, data, stack의 세가지 의미있는 공간으로 구성되는데에 대해
code segment, data segment, stack segment로 잘라 각각의 세그먼트를 필요 시
물리적인 메모리의 다른 위치에 올려놓을 수 있게끔 함. - segment는 프로그램의 주소 공간을 구성하는 의미 단위이기 때문에 위 예시보다 더 잘게 자를 수도 있다.
ex) 각각의 함수들 단위로 자르기 - segment 크기가 균일하지 않기 때문에 dynamic storage-allocation problem이 해당 기법에서도 발생하긴 한다.
- 하지만 통째로 올리지 않고 잘라서 산발적으로 올린다는 특징 존재
대신 불연속 할당을 쓰게 되면 MMU에 의한 주소 변환을 페이지 별로 해야되기 때문에 바인딩이 더 복잡해진다.
Paging
- Process의 virtual memory를 동일한 사이즈의 page 단위로 나눔
- Virtual memory의 내용이 page 단위로 noncontiguous 하게 저장됨
- 일부는 backing storage에, 일부는 physical memory에 저장
Basic Method
- physical memory를 동일한 크기의 frame으로 나눔
- logical memory를 동일 크기의 page로 나눔(frame과 같은 크기)
- 모든 가용 frame들을 관리
- 주소 변환이 page 단위로 이루어져야 하기 때문에 register 두 개를 이용해서는 불가능하고
page table을 사용하여 logical address를 physical address로 변환 - 같은 크기로 잘라놨기 때문에 External fragmentation이 발생하지 않음
- Internal fragmentation 발생 가능
-> 프로그램의 크기가 페이지 크기의 배수가 되리란 보장 x - page table은 각각의 프로세스마다 존재한다.
Implementation of Page Table
- Page table은 main memory에 상주
- Page-Table Base Register(PTBR)가 page table을 가리킴
- Page-Table Length Register(PTLR)가 테이블 크기를 보관
- 모든 메모리 접근 연산에는 2번의 memory access 필요
-> page table 접근 1번, 실제 data/instruction 접근 1번 - 속도 향상을 위해 associative register 혹은 Translation Look-aside Buffer(TLB)라 불리는
고속의 lookup hardware cache 사용 (주소 변환을 위한 캐시 메모리)
Associate Register
(=Translation Look-aside Buffer, TLB)
- TLB는 page table에서 빈번히 참조되는 일부 엔트리를 캐싱중
- CPU가 논리적인 주소를 주면 메모리 상의 page table 접근 전에 TLB에서 먼저 검색
- TLB는 특정 항목만 검색하는게 아닌 전체를 검색해서 순차적으로 검색한다면 시간이 오래 걸림
-> Associative registers를 사용해 parallel search(병렬적 탐색) 가능 - page table은 프로세스마다 다르기 때문에 TLB는 context switch 때 flush 된다. (remove old entries)
Effective Access Time
(=메모리 접근 시간)
Two-Level Page Table
(=2단계 페이지 테이블)
- 기존 방법보다 시간은 더 걸리지만 page table을 위한 공간을 줄이는 방법
- 현대의 컴퓨터는 메모리 주소 체계가 매우 커짐
- 32 bit address 사용 시: 2^32 B(4GB)의 주소 공간
- page size가 4K 시, 1M개의 page table entry 필요
- 각 page entry가 4B 시, 프로세스당 4M의 page table 필요
- 그러나, 대부분의 프로그램은 4G의 주소 공간 중 지극히 일부분만 사용하므로
page table 공간이 심하게 낭비된다.
- 위의 이유로 page table 자체를 page로 구성
- outer-page table은 전체 logical memory 크기만큼 만들어지지만
사용되지 않는 주소 공간에 대한 outer page table의 엔트리 값은 NULL
(대응하는 inner page table이 없음) - page table로 만들 때 사용되지 않는 중간 공간의 엔트리를 안만들 수 없어
maximum logical memory의 크기만큼 page table의 엔트리 수가 만들어지는 것과 대조됨 - 그만큼 매우매우 사용되지 않는 공간이 많기 때문에 2단계 page table이 더 효과적이다.
Address-Translation Scheme
2단계 페이징에서의 주소 변환
728x90
'CS (Computer Science)' 카테고리의 다른 글
[운영체제] 7. Memory Management (5) - 정리 (0) | 2023.05.17 |
---|---|
[운영체제] 7. Memory Management (4) (0) | 2023.05.17 |
[운영체제] 7. Memory Management (2) (0) | 2023.05.11 |
[운영체제] 7. Memory Management (1) (0) | 2023.05.10 |
[운영체제] 6. Deadlock (0) | 2023.05.09 |