PintOS P3 #2 : Page/Frame 정리

VM을 구현하기 전에 Page와 Frame에 대해 좀 더 빡빡하게 굴어야한다는 말에 간만에 질문 수준을 높인 질의응답을 나의 새로운 삼촌 Per에게 도움을 받을 수 있었다. 깃북에서 파고 들기 위한 시도를 한번 간단하게 보고, 궁금증이 해결 되길 기대한다.

---

2025.05.29 - [구현하기] - PintOS P3 #1 : Virtual Memory 서론

PintOS P3 #1 : Virtual Memory 서론

이 글에서 이어진다.
 

Gitbook에서 이야기하는 Page/Frame에 대한 설명부터 구경하자

 

• 페이지
  • 페이지는 페이지 크기인 4KB 길이의 연속된 가상 메모리 영역을 말한다. 페이지는 페이지 정렬되어야 하며, 이는 페이지 크기로 나누어 떨어지는 가상 주소에서 시작해야 함을 의미한다. 따라서 64비트 가상 주소의 마지막 12비트는 페이지 오프셋이다. 상위 비트들은 페이지 테이블의 인덱스를 나타내는 데 사용된다. 64비트 시스템에서는 4 Level Page Table을 사용하여 가상 주소가 다음과 같이 구성된다 :
• 63 - 48 : Sign Extend
  • 47 - 39 : PML4 Offset (즉, 4레벨 페이지 테이블을 말함)
    • 38 - 30 : PDP Offset
      • 29 - 21 : PD Offset
        • 20 - 12 : PT Offset
          • 11 - 0 : Page Offset

• 각 프로세스는 독립적인 가상 페이지 세트를 가지며, 이는 가상 주소 KERN_BASE 아래의 페이지들이다. 반면 커널 페이지 세트는 전역적이어어서 실행 중인 쓰레드나 프로세스에 관계없이 같은 위치를 유지한다. 커널은 사용자와 커널 페이지 모두에 접근 할 수 있지만, 사용자 프로세스는 자신의 사용자 페이지에만 접근 할 수 있다.

 

• 프레임
  • 프레임은 연속된 물리 메모리 영역이다. 페이지와 마찬가지로 프레임은 페이지 크기이고 페이지 정렬되어야 한다. 따라서 64비트 물리 주소는 프레임 번호와 프레임 오프셋으로 나눌 수 있다 :
    • 상위 52비트는 Frame Number, 남은 하위 12비트는 Offset
  • x86-64는 물리 주소에 직접 접근하는 방법을 제공하지 않는다. PintOS는 커널 가상 메모리를 물리 메모리에 직접 매핑하여 이 문제를 해결한다. 커널 가상 메모리의 첫 번째 페이지는 물리 메모리의 첫 번째 프레임에, 두 번째 페이지는 두 번째 프레임에 매핑된다. 따라서 프레임은 커널 가상 메모리를 통해 접근 할 수 있다.

 

 

Page와 Frame에 대해 좀 더 논했더니

Page와 Frame은 정확한 1:1 대응 관계이다. 정확하게는, Page는 가상 메모리 상의 4KB 크기 단위이고, 논리적 개념으로써 논한다. Frame은 물리 메모리 상의 4KB 크기 단위이며, 물리적 개념으로 논한다.\하나의 Page는 하나의 Frame에 매핑이 이루어지는 것이다.

이렇게 논함을 분리한다는 것은 한 뭉치의 4KB가 Page로써 존재하냐, Frame에 담기느냐에 대한 전환점에서 예외 처리, state 전환등 다양한 것을 고려해야하게 됨을 뜻한다. 주요 고려사항이 정말 많다. 이런게 있구나만 짚자. 

1. Page State Management | 페이지 상태 관리
2. Page Fault Handling 복잡성
3. Frame Allocation Challenges
4. Address Translation Consistency
5. Synchronization Issues
6. Memory Consistency
7. Resource Management
8. Error Recovery

우리가 Page와 Frame을 구분해서 논하더라도 Page 자체는 변하지 않는다. Page는 가상 메모리의 논리적 주소 공간에서 항상 존재하게 된다. 우리가 이것을 대하는 단어가 바뀌는 것은 어디에 위치하느냐에 의한 것이다. Page는 Frame이라는 Container에 담긴다는 표현을 쓰곤한다.

Page의 4KB 단위는 일관되게 유지되어 RAM, 디스크, MMU 처리에서 모두 4KB로 나뉘어진다. 그렇다면 내가 바로 생각나는 건 이것이다 :

• 6KB짜리는 어떻게 남겨질까?
• 정말 다양한 크기의 데이터가 있고 이것들은 4KB 단위로 나누면 무지막지하게 많은 조각들이 된다. 이것들이 연속적으로 불러와 질 수 있는지에 대한 인지는 어떻게 할까?

 

6KB 짜리는 어떻게 남겨질까?

이건 이전의 정글 교육과정에서 언급했듯 4KB를 채우고, 남은 2KB를 채운다. 그러고 끝난다. 빈 2KB가 발생하지만 그걸 따로 활용 할 수 있는 수단도 없다. 실제로 이에 대한 나노단위 최적화를 시도하려 했던 시도가 있었다고 알려져 있다. 일반 시스템에는 채택되지 않았다.

 

연속적 파일에 대한 인지는 어떻게 가능할까?

이러한 정의를 들은 즉시 이어서 이러한 생각을 했다 :

SPT가 메타데이터를 조회함으로 써 어느 파일이 Page Fault로 인한 위치 재조회 요청이 있었는지에 대해 확인한다고 한다.

funny.txt 파일의 첫 번째 페이지가 SPT의 100번째 엔트리에 해당한다면, funny.txt의 두 번째, 세 번째 페이지들에 대한 Page Fault 발생 시 SPT에서 어떻게 해당 페이지들의 위치를 찾을 수 있는가?

우선 SPT에 100번째 무언가는 좀 부적절한 표현이라고 한다. SPT는 가상 주소를 키로 사용하므로, 실제 매핑이 이렇게 이루어진다 :

// 예시: funny.txt 매핑
가상 주소 0x10000000 → funny.txt의 0~4095 바이트 (첫 번째 페이지)
가상 주소 0x10001000 → funny.txt의 4096~8191 바이트 (두 번째 페이지)  
가상 주소 0x10002000 → funny.txt의 8192~12287 바이트 (세 번째 페이지)

그리고 SPT는 연속적의 개념을 특별히 인지하고 있지도 않다. 그냥 한 파일에 대해서 SPT가 연달아 주르륵 놓는것 뿐이다.

그냥 손이가는대로 뻗어보니 순서대로 놔진 것이라고 생각하면 된다.

SPT가 이것을 가능하게 하는 이유는 총 세 가지이다 :

1. 독립적 엔트리 관리 : 각 가상 페이지마다 별도의 SPT 엔트리가 존재한다.
2. 완전한 메타데이터 : 각 엔트리에 파일 정보, 오프셋 등이 완전히 포함되어 있다.
3. 해시 테이블 특성 : O(1) 시간에 임의 가상 주소의 정보를 조회 할 수 있다.

그 말인 즉슨 한 파일의 4095-4096 번째가 자연스럽게 연결된다는 것인데?

Yes. 앞에서 말했듯 SPT는 그냥 놓고보니 연속이네 ㄷㄷ 이러고 마는것이다. 물론 실제로 그런 경향성만 있으니 특별히 따로 검색을 하고 자시를 할 논함이 필요 없는 것.

이어서 논하면, 프로그램은 이것을 연속된 메모리로 인식하지만, 0-4095 한 덩어리가 한 칸, 4096- 은 바로 옆칸이 아닌 다른 내용에 저장 될 수 있다. 이렇게 배치됨에도 연속적이 가능한 이유는, SPT에서 가져와서 이제 진짜 쓸 일이 있다는건 C언어의 포인터 등에서 다양한 방법을 통해 manipulate가 가능해진다는 것이다. 거기서부턴 사람의 재량인것이다.

manipulate는 조작의 뜻이 있는데 이게 한글의 워딩으로써의 조작은 너무 안좋은 워딩이라 이렇게밖에 못쓰겠다.

여담으로 테이블이라서 너무 거창한것을 생각하는데, 그냥 컴퓨터 입장에서 정해진 양식에 맞춰 적어놓는다고 생각하면 마음이 너무 편하다.