[운영체제] 8. 메모리

임호연·2021년 5월 21일

기록

목록 보기

9/20

메모리

기본적인 메모리 영역 나누는 방법

limit = 120900

base = start address 300040

메모리 바인딩

링커나 로더가, 메모리에 실제로 올리게 된다.

바인딩 시점에 따른 구분

컴파일 시간에 하는 바인딩

그냥 컴파일 때 특정 주소로 박게 된다.

만약 주소가 바뀌어야 하면 다시,,
적재시간에 바인딩

재배치 가능하도록 컴파일을 한다.

로더가 메모리에 올릴 때 바인딩한다.
실행시간에 바인딩

실행시간에도

메모리 상에서 위치가 막 변한다.

논리주소대 물리주소

동적 적재

overlay를 말하는 듯.
프로그램 전체가 올라올 필요는 없는데 현재 그렇게 되어 있으니까, 비효율적이다.
직접 만들어야 되기에 귀찮다.
필요한 모듈만 싹싹 올라오기

DLL

배경

만약, 어떤 공유라이브러리가 있다고 하자.
만약, 로더가 이거를 배치하려고 하면, 링커 단에서 공유라이브러리에 대한 재배치 가능한 오브젝트 파일을 항상 연결해서 실행파일을 만들어야 한다.
이게 낭비이기 때문에, 현재 메모리에 적재된 공유 라이브러리를 찾아서 올리자!

이렇게 하기 위해서는, 실행시간에 적재되어야 한다.
유지보수가 쉬워지겠지.

연속할당 방법

연속적 할당 방법 세가지

워스트 핏은, 큰 가용공간. best fit은 작은 가용공간
실험적으로, 시간과 공간 효율성이 최초, 최적 > 최악이다.
최초적합이 일반적으로 조금 더 빠르다.

단편화

원인 : 다른 할당 단위 용량, 연속적인 위치

외부단편화

잦은 적재와 삭제로

프로세스 사이 공간이

정말 파편화가 심하게 되는 경우
0.5N법칙이라는게 있다.

반은 버리더라,,
압축하는 방법

그냥 한 쪽으로 다 몬다.

재배치가 실행시간에 동적으로 정해질 때만 가능하겠지.

이전처럼, 로더에 모두 몰빵되어있다면 힘들다.

내부 단편화

딱 맞게 하기 보다는 어느 정도 일정한 사이즈로 메모리를 할당해주게 된다.
할당한 가용공간에서 프로세스가 메모리를 다 사용하지 않는 경우

페이징

기본적인 페이지의 구조

페이지 address

2^(m-n) = page number
2^(n) = 페이지에 포함된 바이트의 크기라고 볼 수도 있을듯.
64bit 운영체제, 한 페이지의 크기가 4KB(2^12)이라면, 2^52가 페이지 테이블 개수로 들어간다.

내부단편화 문제

프로세스의 마지막 페이지는 조금 비어 보일 수도 있다.
작은 파일은 작은 페이지단위가 효율적이고, 큰 파일은 큰 페이지 크기가 효율적이다. 따라서, OS에 따라서 여러개의 페이지 테이블 크기를 가진다.

페이지 테이블

각 프로세스 마다 저장하고 있다.
PTBR 레지스터를 프로세스로 바꾸게 함으로써, 문맥교환 코스트를 줄인다.

프레임 테이블

가용한 빈 공간을 유지하기 위해

TLB

엔트리들
- dont cache
- dirty bit
- valid
- global
set associative, full associative, direct-mapped

탐색시간은 영향을 거의 미치지 않고, 애초에 TLB를 태워도 파이프라인으로 잘 처리가 되서 괜찮다.
set associative에서는 뒷 주소를 사용해서, 한쪽으로만 안 쓰이도록et associative에서는 뒷 주소를 사용해서, 한쪽으로만 안 쓰이도록
중요 커널코드를 고정하는 경우도 있다.
ASID : 프로세스의 번호를 TLB에 넣어 놓는다.

프로세스마다 페이지 넘버는 중복될 수 있다.

다른 프로세스가 접근하는 것을 막기 위해,

그냥 TLB를 날려버리는 거를 방지하기 위함.

프로세스 번호가 다르면 tlb miss를 낸다.
사실 실제로는 멀티레벨로 구현되어 있다.

실질접근시간

메모리 접근이 한번 줄어든다. 따라서, (hit) 메모리접근시간 + no_hit 메모리접근시간 * 2 가 된다.

겁나 자세한 TLB 사진

페이지 테이블 엔트리

읽기, 쓰기 권한을 페이지에 할당 가능. 만약 오버랩 될 시 트랩을 건다.
페이지 테이블 entry에 어떤 페이지가 무효로 박혀 있으면, 이제 valid 하지 않다는 것이므로 만약 이 주소공간을 보려고 하면 trap을 한다.
PTLR값이 있다 → 전체 주소공간을 진짜 다 사용하려고 하면 너무 아까우니까, 그냥 프로세스에게 할당을 해서,, (예를 들면 페이지 개수 2^6만 하세욧!) 이 값을 넘으면 trap하도록 한다.

공유 메모리

이렇게,, 같은 페이지 메모리를 참조하게 해서 용량을 확 줄일 수 있다.

ZERO COPY I /O

만약, 커널로 어떤 데이터가 들어오고 이를 유저공간에 뱉어야(copy) 할 때
그냥 페이지테이블 포인터만 바꿔버리면 해결 real copy 없이 해결

페이지 테이블의 구조

필요한 이유

32bit
페이지의 크기 12bit(4kb)
그렇다면, 페이지의 개수 = 페이지 테이블 = 2^20 = 1M

하나당 4Byte니까 4MB가 된다.

계층적 페이지

불연속할당기법이라고도 할 수 있겠네요라고도 할 수 있겠네요
쪼개서, 안 쓰는 마지막 페이지 테이블은 공란으로 남겨둘 수 있다.
3번 참조하게 된다.

해시 페이지 테이블

p를 이용하여 해시함수를 쓴다
해시 함수의 value는, 프레임 위치 및 원래 페이지 테이블에 있던 각 정보가 담긴다.
충돌 체이닝으로 관리
변형

클러스터 페이지 테이블

hash의 결과가, 한 16개 정도의 페이지를 담은 테이블인거임.

그러면, 거기서 페이지를 뽑아서 쓸 수 있게끔

역 페이지 테이블

커널에, 딱 하나의 역 페이지 테이블만 존재합니다.
process id와 page number로 조회를 한다

이 때, 오버헤드가 생길 수 있다.

해시테이블을 이용하면 조금 덜 할 수 있다.

pid, page number로 해시한 결과에다가, 프레임 넘버를 저장하면 바로바로 찾을 수는 있다.

하지만, 해시테이블을 또 참조해야 하는 결과가 있을 수도 있다.
엔트리 안에 프레임 넘버가 있다
그냥 역 페이지 테이블 안에 없으면 메모리에 없는 거임
공유메모리 할당이 조금 애매하다.
생각해볼 점들

페이지 테이블에서, 어떤 페이지가 스왑공간의 어디에 적재되어 있어야 하는 지를 확인하기가 어렵기 때문에, 이를 위한 별도의 공간이 필요하다. 그러면 어차피 그만큼의 공간이 필요한 것이 아닌가?
- 페이지 폴트 시에만 필요하기 때문에, 그게 필요한 건 맞지만 이를 디스크에 저장시켜 놓아도 된다.
- 따라서, 결국에는 메모리 용량을 덜 차지한다.