2020-11-20 운영체제 기초(11) 메모리
메모리관리
- 물리주소와 논리주소
- 논리주소(virtual address)
- 프로세스마다 독립적으로 가지는 주소공간
- 각 프로세스마다 0번부터 시작
- cpu가 보여주는 주소는 논리주소
- 물리주소 : 메모리에 실제 올라가는 위치
- 주소바인딩 : 주소를 결정하는것, Symbolic address -> 논리주소 -> 물리주소
주소바인딩
- compile time binding
- 물리적 메모리주소가 컴파일 시 알려진다
- 시작위치가 변경되면 다시 재컴파일
- 컴파일러는 절대코드 생성
- load time binding
- 로더의 책임하에 물리적 주소 부여
- 컴파일러가 재배치가능코드를 생성한 경우 가능
- execution time binding(= runtime binding)
- 수행이 시작된 이후에도 프로세스의 메모리상 위치를 옮길 수 있다
- cpu가 주소를 참조할때마다 바인딩을 점검
- 하드웨어적인 지원이 필요(base register, limit register, MMU)
CPU가 바라보는 주소는 논리주소
Runtime Binding
- MMU(Memory-Management Unit) : 논리주소를 물리주소로 매핑(변환)하는 하드웨어
- MMU Scheme : 사용자 프로세스가 CPU에서 수행되면서 생성하는 모든 주소값에 대해 base register값을 더한다.
- user program : 논리주소만 다룬다. 실제 물리주소는 볼 수 없다.
- limit register는 프로그램의 크기를 가지고 있다. CPU가 논리주소를 요청하면 논리주소가 프로그램의 크기보다 큰지 체크하는 역할을 한다. 크면 trap이 걸린다.
- relocation register : 접근할 수 있는 물리주소의 최소값
###Dynamic loading
- 프로세스 전체를 메모리에 미리 다 올리는게 아니라 필요할때마다 메모리에 올린다.
- 메모리 utilization 향상 => 자주 사용안되는 코드들이 메모리에 올라가면 비효율적인데, 동적로딩을 하면 효율적.
- OS의 지원없이 프로그램에서 자체 구현 가능
###Overlays
- 프로세스에서 실제 필요한 부분만 메모리에 올린다.
- 프로세스의 크기가 메모리보다 클때 유용. 초창기 컴퓨터 시스템은 메모리가 작아서 이때 많이 활용됬다.
- 운영체제의 지원이 없어서 프로그래머가 직접 구현했기 때문에 많이 어렵다.
Swapping
- 프로세스를 메모리에서 backing store(=swap area, 하드디스크)로 쫓아낸다.
- 중기스케줄러(swapper)에 의해 swap out시킬 프로세스를 선정
- priority based cpu scheduling algorithm
- 우선순위가 낮은 프로세스를 swap out 시킨다
- 우선순위가 높은 프로세스를 메모리에 올린다
- 컴파일 타임, load time binding이 사용되면 swap out이 됬다가 swap in이 될때 원래 메모리 주소로 올라가야한다. 효율적으로 지원되기 위해서는 runtime binding이 필요
- swap time은 대부분 transfer time(swap 되는 양에 비례하는 시간)이다.
Dynamic Linking
- Linking : 소스파일을 하나의 실행파일로 만드는 과정
- linking 시간을 실행시간까지 미루는 방법
- static lining
- 라이브러리가 프로그램의 실행 파일 코드에 포함
- 실행파일 크기가 크다
- 동일한 라이브러리를 각각의 프로세스가 메모리에 올려서 메모리낭비가 된다.
- dynamic linking
- 라이브러리가 실행시 연결된다
- 라이브러리 호출 부분에 라이브러리 루틴의 위치를 찾기 위한 stub이라는 작은 코드를 둔다.
- 라이브러리가 이미 메모리에 있으면 루틴의 주소로 가고, 없으면 디스크에서 읽는다
- OS의 도움이 필요
Reference
- https://www.enterprisestorageforum.com/imagesvr_ce/3580/memory-swapping.jpeg
- https://user-images.githubusercontent.com/37807838/44186821-97bff800-a156-11e8-9e80-58bf8eb20dfb.png
Written on November 22, 2020