Memory Management - 2

김세영·2021년 6월 10일
0

Shared Pages

어떠한 프로그램을 작동하는데,
코드 용량이 150KB이고 데이터 용량이 50KB라고 가정하자.
프로세스 40개가 이 프로그램을 사용한다 할 때,
8000KB [(150 + 50)KB * 40]이라는 용량이 사용된다.

하지만, 코드는 프로그램 실행 도중 절대로 바뀔 수 없다.
코드는 보안, 오동작의 문제 때문에 절대 프로그램
실행 도중 변경될 수 없다.

따라서 이 코드에 해당하는 용량은 바뀌지 않으므로, (Readonly)
코드를 하나의 공간에 두고, 여러 프로세스가 참조해도 문제가 되지 않는다.
이 때 총 사용되는 용량은 150KB + 40 * 50KB = 350KB로, 현저히 줄어든다.

이렇게 공유되는 Page를 Shared Page라 한다.

Example for Shared Pages

  • 컴파일러, 윈도우 시스템, 런타임 라이브러리, 데이터베이스
  • 공유 메모리(Shared Memory)

Hierarchical Page Table

32bit 시스템에는 2322^{32}개의 Page Table Entry가 존재한다.
Page size가 4KB (2122^{12}KB)이고,
PTE size가 4byte라고 하면

PTE 개수: 232÷212=2202^{32} \div 2^{12}=2^{20}
Page Table Size: 220×4=222=42^{20} \times 4=2^{22}=4 MB

이 때 4MB라는 용량에 대해 Contiguous Allocation을 진행한다면
부하가 매우 심하고 느리기 때문에,
Page Table을 나누어 관리하는 Hierarchical Page Table이 도입되었다.

Page of Page Table

DRAM에서 Page를 쪼개어 관리하기 위해
Page of Page Table이란 것이 등장했다.
이로 인해, 쪼개어진 Page of Page Table에 접근하기 위해서는
또 다른 테이블이 필요해졌는데, 이 테이블을 Outer Page Table이라 한다.
(Page Table of Page Table이라고도 한다. ?)

32bit 시스템에서 Virtual Address가 32bit일 때
Virtual Address는 다음과 같이 구성된다.

[p1(10) + p2(10) + d(12)]
p1: Outer page table의 인덱스
p2: Page of Page table의 인덱스
d: Frame no

TLB

CPU와 MMU는 프로세서에 있기 때문에 속도가 매우 빠르지만,
Page table은 DRAM에 있기 때문에 접근 속도가 상대적으로 느리다.
이 속도를 보완하기 위해 TLB라는 캐시를 프로세서에 추가한다.

CPU에서 Virtual Address가 나오면, 먼저 Page Number을 TLB에서 찾는다.

TLB Hit
이를 바로 Physical Address로 변환하여 DRAM에 접근한다.

TLB Miss
Page Table을 참조하여 Physical Address를 가져온 후,
다시 프로세서에서 DRAM에 접근한다.


Locality

반복적으로 접근되는 메모리의 위치, 변수, 관련된 저장 위치 등을 Locality라 한다.


void func1() { ... } // Page 1

void main() // Page 2
{
    func1();
    ... = malloc(...);
}

void* malloc(...) { ... } // Page 3

위 코드에서 Page2가 실행되면 Page1, 3은 무조건 실행된다.
이처럼 서로 인접한 페이지들을 접근하는 현상을 Spatial Locality라 한다.


...

int i = 1;
int j = i;
i = j++;
for (i = 0; i < 10; i++) { ... }

...

위 코드와 같이 i가 짧은 시간 안에 여러 번 접근되는 현상을
Temporal Locality라 한다.


Working Set

프로세스가 가까운 미래에 사용할 메모리 양을 계산하여, 각각의 프로세스에게 그 메모리 양을 보존해주어 Page Fault를 줄이자는 이론이다.

하지만 가까운 미래를 예측할 수 없기 때문에, 이론으로만 존재하게 된다.


tt시점에서 과거의 Δ\Delta시간만큼 접근된 페이지들의 개수가 Working set의 크기가 된다.
위 예시처럼 시간에 따라 Working Set은 바뀔 수 있어서, 공간 낭비가 발생할 수 있다.

profile
초보 iOS 개발자입니다ㅏ

0개의 댓글