운영체제 11주차
부산가톨릭 대학교, 컴퓨터공학과
변상선
Memory management
•
Background•
Program must be brought (from disk) into memory and placed within a process for it to be run•
Main memory and registers are only strorage CPU can access directly•
Memory unit only sees a stream of address + read request, address + data and write request•
Register access in one CPU clock•
Main memory access can take many cycles, causing stall•
Cache sits between main memory and CPU registers•
Memory protection is required to ensure correct operationHardware memory protection
• 사용자 프로세스가 다 른 프로세스나 커널의 메모리 영역에 접근하 는 것을 허용해서는 안 됨
• Base & limit registers
• 해당 프로세스가 접
근할 수 있는 메모리
영역을 표시
Address binding
•
프로그램의 모든 명령어와 함수 및 변수가 실제 메모리의 어느 주소에 배치되는가?•
Source code: 변수명, 함수명•
Assembly로 번역된 코드•
프로그램의 시작으로부터 offset으로 표현•
ex) 14 bytes from beginning of this module•
Loader•
메모리에 프로그램이 적재되면 offset 값들을 실제 주소로 변경•
프로그램의 시작주소 + offset•
로딩 이후 프로세스 (전체 또는 일부)의 주소가 실행도중 바뀌거나 재실행시 바뀐다 면?•
재바인딩 => 느리다•
Dynamic linked library => 실행시간에 링크 및 바인딩프로그램 처리 과정
Virtual address
•
Logical address (virtual address)•
Execution-time address- binding scheme•
프로세스의 메모리 접근은 항상 가상메모리로 => 메모리 접근이 발생 할 때마다 가상메모리가 물 리 메모리로 맵핑•
맵핑하는 하드웨어 => MMU& TLB
•
재배치 재바인딩이 전혀 필요 없음Virtual memory
Memory management unit (MMU)
• Hardware device that at run time maps virtual to
physical address
Dynamic linking
•
Static linking library•
실행 프로그램이 만들어질 때 모든 외부 참조 라이브러리들도 함께 컴파일되어 링 크, 그리고, 함께 적재•
Dynamic linking library=> 실행할 때, 링크 및 적재•
컴파일만 되어 디스크에 대기•
호출될 때 메모리로 적재 및 재배치 그리고 링크•
동적 라이브러리가 호출되는 부분•
컴파일러가 Stub 코드 삽입•
동적 라이브러리의 위치 (메모리 또는 디스크)를 찾아서 필요하면 적재를 요청 하고 라이브러리의 주소를 알아낸다•
그 다음에 동일한 라이브러리 호출시 해당 주소에 있는 라이브러리 호출 (다시 링크 및 적재할 필요 없음)Shared library
• 같은 동적 라이브러리를 여러 프로세스가 동시 에 호출한다면?
• 각 프로세스에게 동일한 라이브러리를 별도로 동적 링크-적재해서 사용하게 하는 것은 낭비
• 하나의 동적 라이브러리를 모든 프로세스가 공유하게 하는 것
• 모든 시스템 콜은 공유 라이브러리
Swapping
• 실행중인 모든 프로세스가 요구하는 메모리 크기 >> 실제 물리 메모리 크기
• 모든 프로세스를 물리메모리에 올릴 수 없 다
• 일부는 디스크에 존재
• 스케쥴러 디스패쳐는 ready 상태에 있는 프로세스를 실행할 때마다 해당 프로세스 가 메모리에 없으면 불러와야 함 => swap in
• 만약, 물리 메모리 공간이 부족하다면, 기존 프로세스를 디스크로 밀어내어 공간을 확보해야 함 => swap out
• 문맥교환시간의 대부분
Swapping
•
Swap in 할 때, 프로세스 전체를 하게 되면 시간이 너무 많이 걸림•
100MB => 2초, 3GB => 60초•
따라서, 프로세스 전체가 아닌 당장 실행이 되어야 하는 부분만 swap in => 가상 메모리의 paging•
Swap out 될 프로세스의 선택•
완전 휴지 상태에 있는 프로세스 => I/O 상태를 기다리고 있는 프로 세스도 선택되면 안됨•
현대의 운영체제 (Linux, Windows, UNIX)•
자유 메모리가 임계량보다 부족하게 되면 swapping을 시작•
JAVA => 주기적인 garbage collectionSwapping on mobile system
•
스마트폰의 경우 디스크보다는 flash memory를 사용•
flash memory는 쓰기 횟수에 제한 => wear leveling•
따라서, 모바일 OS는 swapping을 지원하지 않음•
iOS•
주기적으로 어플리케이션에게 메모리를 반환할 것을 요구 => 읽 기 전용 부분 위주로•
반환하지 못하면 응용프로그램을 강제로 종료•
Android•
iOS와 비슷, 하지만, 강제로 종료된 프로세스를 flash에 저장하였 다가 다시 빠르게 재시작하는 것을 지원Contiguous allocation
• 초기 메모리 할당 방법
• 크게 운영체제가 사용하는 메모리 (low memory)와 사용자 프로 세스가 사용하는 메모리 (high memory)로 분리
• 또, 각각의 사용자 프로세스는 하나의 연속된 메모리 공간을 사용
• 각각의 메모리 공간은 limit register와 base register로 보호
Contiguous allocation
OS process 5
process 8
process 2
OS process 5
process 2
OS process 5
process 2
OS process 5 process 9
process 2 process 9
process 10
Contiguous allocation
•
Static partition•
모든 프로세스에게 동일한 고정된 크기의 영역을 할당•
Multiprogramming degree = max. # of partition•
Dynamic allocation•
운영체제가 자유 메모리 영역을 유지•
프로세스 실행 요청 => 메모리 할당 => CPU 할당•
실행이 종료되면 메모리를 반납 => 다른 프로세스가 사용할 수 있음•
메모리를 할당 할 때, 어떤 비어있는 메모리 (hole)를 할당할 지 결정•
Hole 리스트를 운영체제가 유지•
프로세스의 메모리 요청이 들어오면? hole 리스트에서 어떤 hole을 선택해서 해 당 프로세스에게 줄 것인가?•
최초 적합, 최적 적합, 최악 적합 => 단편화 (fragmentation) 생성Fragmentation
•
연속되지 않은 작은 자유 메모리 공간들 => external fragmentation•
프로세스에게 할당되기에는 너무 작다•
하지만, 이들을 모두 모으면 프로세스에게 할당될 수 있다•
프로세스에게 할당이 되었으나 실제 프로세스가 사용하지 않는 공간들=> internal fragmentation
•
해결책•
compaction => 외부단편화를 해결하기 위해 프로세스들을 재배치 해서 연속된 큰 공간을 확보하는 것 => 재배치가 동적으로 가능해 야 가능 => 시간이 많이 걸림•
Segmentation & pagingSegmentation
•
프로그래머가 생각하는 대로 논리적인 메모리 뷰를 제공해주는 방식•
A program is a collection of segments•
A segment is a logical unit such as•
main program•
procedure (or function or method)•
object•
variables (local, global)•
stack•
symbol table•
arraySegmentation
• 프로그래머가 생각하는 프로그램의 모습
Segmentation
1
3
2
4
1 4
2
3
user space physical memory space
Segmentation
• 세그멘테이션에서 logical address
• <segment number, offset> 로 표현
• Segment table
• segment number => 실제 세크먼트의 물리주소로 맵핑
• base - segment의 시작 주소
• limit - segment의 크기
• STBR (segment-table base register)
• 실행중인 프로세스의 세그먼트 테이블 저장된 곳의 시작 주소 (메모리 상)
• STLR (segment-table length register)
• 실행중인 프로세스의 세그먼트의 갯수
Segmentation hardware
Paging
•
고정된 균등한 크기로 전체 메모리를 분할•
물리 메모리 => frame•
운영체제는 free frame을 항상 유지•
가상 메모리 => page•
프로세스가 메모리를 요청할 때 요청한 메모리 만큼 page를 할당•
page와 frame은 같은 사이즈•
N개의 page를 갖는 프로세스가 실행되기 위해서는 N개의 frame이 물리 메모리에서 확보 되어 야 함•
frame은 연속되어있을 필요가 없음 => 외부단편화 해결•
하지만, 여전히 내부단편화는 존재•
해결책?•
페이지 사이즈를 작게 한다 => 너무 많은 페이지 엔트리가 존재 => 페이즈 테이블 의 크기 증가Address translation scheme
• < page number, page offset >
Paging model of logical
and physical memory
Free frames
Before allocation After allocation
Implementation of page table
•
현재 실행중인 프로세스의 page table은 메인 메모리에 위치•
PTBR (page table base register) => page 테이블 시작 주소•
PLTR (page table length register) => page 테이블의 크기•
모든 명령어/데이터의 접근은 결과적으로 두 번의 메모리 접근을 유발•
페이지 테이블이 있는 영역에 접근, 그리고, 실제 명령어/데이터가 있는 메모리 영역에 접근•
TLB (translation-lookaside buffer)•
두번의 메모리 접근을 줄이기 위한 방법•
최근 접근된 page table entry를 보관하고 있는 일종의 cache•
하나의 프로세스만을 위한 또는 모든 프로세스를 위한? => 장단점Paging with TLB
Memory protection
•
Per page•
Read only, read/write, execute only etc•
Valid-invalid•
page table을 모든 프 로세스가 공유하는 경 우•
해당 프로세스에게할당된 page만 접 근하도록 제어 =>
valid or invalid bit
Shared pages
•
하나 이상의 프로세스에 의해 공유 되는 page•
IPC를 위한 shared memory•
Reentrant code shared among processes•
시스템 콜Page table 구조
• 현대의 32-bit 컴퓨터
• 4KB의 page size
• 4GB의 메모리 공간
• 따라서 4KB/4GB = 1M개의 페이지를 가짐
Hierarchical page table
•
Two or multilevel page tables•
page table의 page table을 유지Two-level paging example
•
32 bit address•
Page size 1KB•
한 페이지 내 주소공간 구분을 위해•
10 bit•
나머지 22 bit로 페이지 번호를 구분•
따라서 총 222
개의 페이지를 가짐
•
Two-level page의 경우 22 bit를 다시 쪼갤 수 있음page number page offset
p1 p2 d
12 10 10
