왜 이 주제에 대해서 다루기로 했었나?

<2023년 10월의 다나와 데스크탑용 DDR5램 순위>

핀토스를 공부하던 중 메모리 블록(또는 메모리 청크)의 크기가 4kb인건 현재 컴퓨터 환경과 너무 동떨어진게 아닌가 하는 의문이 들었다. 굳이 산업용 슈퍼컴퓨터가 아니라도 개인용 컴퓨터에 램을 32gb, 64gb씩 달 수 있는 시대에 어째서 메모리를 나누는 단위가 4kb인가?
이에 대한 답을 구하고, 이 발표자료를 만들면서 여기에서 대부분의 내용을 참조했다.

size of memory block

memory block의 크기가 작을 때

• 장점: fragmentation이 줄어서 메모리 효율성이 높아진다.
• 단점: 크기가 큰 데이터를 복사할 때 여러번 읽고 써야하므로 overhead가 커진다.

memory block의 크기가 클 때

작을 때와 장단점이 반대가 된다.

결론

즉 둘은 trade-off관계이며 두 장점 사이에서 최적의 효율을 찾는 크기를 결정해야 한다.

역사적인 배경

60-70년대에 가상메모리가 처음 도입되고 적절한 데이터 블록은 얼마인가에 대한 계산이 꾸준히 이루어지고 있었다.
페이징 가상 메모리 기술을 지원한 최초의 인텔 프로세서는 1985년에 출시된 인텔 80386이었고, 4kb를 메모리 블록의 기준으로 사용했다.
70년대 컴퓨터에서 사용 가능한 물리적 메모리의 일반적인 용량은 몇십 ~ 몇백kb 범위였고, 애플리케이션의 작업 세트는 일반적으로 수십 KB에 불과했다. 따라서 16KB 정도의 작은 페이지 크기라도 몇 페이지만 있으면 사용 가능한 물리적 메모리를 모두 소모할 수 있기 때문에 실용적이지 않았다.
1975년에 만들어져 선풍적인 인기를 끌었던 개인용 컴퓨터인 APPLE 2는 MOS Technology 6502라는 8bit 프로세서를 사용했다. RAM 용량은 48kb, 또는 64kb였는데 64kb는 8bit 프로세서가 접근 가능한 최대크기의 용량이었다.
1978년에 만들어진 인텔 8086 16bit 프로세서는 (이름의 86에서 알 수 있듯이 현대 컴퓨터 x86 시스템의 근간이 되는 프로세서이다.) 총 1mb, 2^20byte의 RAM을 지원했다.
만약 오늘날 컴퓨터 시스템에서 메모리 블록을 하나에 4GB씩 할당한다면 금방 메모리가 다 차버릴 것이다. 그 당시에도 비슷한 이유로 16kb는 너무 큰 크기였다.

따라서 70년대와 80년대 초반의 작업 세트 크기와 물리적 메모리 가용성을 고려할 때 페이지 크기는 2^0(1Byte) - 2^14(16KB) 의 범위에서 결정되어야 했다. 그러나 페이지의 크기가 너무 작다면, 일반적인 크기의 데이터를 다루는데도 지나치게 큰 overhead 가 걸린다. 따라서 페이지 크기를 연구한 70년대와 80년대 초반의 논문은 대부분 2^7(128)byte부터 2^14byte(16kb)의 이 8가지 옵션만 연구했다.
당시에 TLB cache (프로세서와 페이지 테이블 사이의 캐시)가 개발중이었는데, 작은 크기의 빠른 캐싱(작은 페이지 크기)과 더 많은 페이지 테이블 항목(큰 페이지 크기)을 캐싱하는 것 사이의 균형을 찾으려는 노력이 있었다.
물론 모든 경우에 적합한 단 하나의 크기는 물론 결정될 수 없었다. 허나 당시 Intel의 주요 고객들이 사용하던 환경에서 가장 적당한 크기는 4kb였고 이 때 인텔이 결정한 크기가 지금까지 이어지고 있는 것이다.

오늘날 시스템에 미치는 영향

32bit system

32bit system 하에서는 가상페이지를 사용하기 위한 페이지 테이블이 2단계면 충분했다.
각 페이지 테이블의 크기 자체도 페이지 하나의 크기를 가져야 하는데, 포인터의 크기가 4 Byte ( 2^2 ) 인 32 bit 컴퓨터에서 하나의 페이지 테이블에 들어갈 수 있는 엔트리의 개수는 1024개 ( 2^10 ) 이다. ( 2^2∗2^10=2^12byte 즉, 페이지 하나의 크기인 4 KiB가 된다.)
상위 페이지 테이블인 Page-Directory는 1024개의 엔트리를 가질 수 있고, 각 엔트리는 하위 페이지 테이블의 시작주소를 담고 있을 것이다. 하위 페이지 테이블인 Page-Table 또한 1024개의 PTE를 가질 수 있다. 그렇다면 총 가능한 PTE의 개수가 2^20개가 되고, 이 PTE에 해당하는 페이지 안에서의 오프셋 또한 페이지의 바이트 크기(4 KiB = 4096 Byte = 2^12) 만큼 가능하기 때문에 결국 가능한 주소의 개수는 2^20∗2^12=2^32개가 된다.

그리고 이 점 때문에 흔히들 말하는 32bit에선 램을 4GB이상 쓸 수 없다는 문제가 발생한다.
32bit환경에선 자신의 메모리를 최대한 할당하더라도 2^32개 이상의 주소를 기록할 수 없고, 2^32 byte는 4gb 이기 때문이다.

64bit system

그리고 64bit 환경에서 pml4를 쓰는 이유도 이와 관련이 있다.
64bit 환경에서는 포인터의 크기가 8(2^3)byte이기 때문에 페이지 테이블 당 엔트리 개수가 512(2^9)개로 줄어든다.
2^3 * 2^9 == 2^12
결국 4단계의 페이지 테이블 구성을 통해 총 가능한 PTE의 개수가 2^9∗2^9∗2^9∗2^9=2^36개가 되고, 페이지 오프셋 개수 2^12 를 곱해주면 가능한 주소의 개수는 정확히 2^36∗2^12=2^48 개가 된다.

아직은 걱정할 단계가 아니지면 4단계 페이지 테이블 하에서 접근 가능한 주소의 개수는 2^48개, 즉 RAM을 256tb 크기까지만 사용할 수 있다. 지금 보면 정말 말도 안 되는 숫자지만 언젠가 이 용량도 부족해져서 64bit system에서 사용가능한 주소를 전부 사용할 수도 있겠다. 그렇게 된다면 사용할 수 있는 RAM의 최대한의 크기는 16 eb(엑사바이트), tb -> pb(페타) -> eb(엑사)의 크기다.