[SW 정글 76일차] Paging 기법

오늘은 Pintos project 3에서 쓰이는 paging 기법에 대해 공부했다.

가상메모리를 고안한 사람은 정말 대단한 것같다..

그리고 paging 기법도 신세계다.

 

 

 

 

1. 페이징 기법

페이징은 주소 공간을 동일 크기의 조각으로 분할하는 것을 말하는데 프로세스의 주소 공간을 가변 크기를 가지는 세그멘트(segment)로 나누는 것이 아니라 고정 크기를 가진 페이지(page)로 나누는 것을 의미한다.

가상 메모리에서 이렇게 고정 크기로 나눈 단위를 페이지라고 부르고 물리 메모리에서도 같은 고정 크기로 나누는데 물리 메모리에서 부르는 단위는 프레임(frame)이라고 한다.

이 프레임 각각은 하나의 가상 메모리 페이지를 저장할 수 있는 것이다.

기본적인 원리는 가상 메모리를 고정된 크기로 나누어 페이지를 만들고 해당 페이지를 물리 메모리의 프레임에 매핑시켜주는 것이다.

여기서 해결해야할 것은 공간과 시간 오버헤드를 최소로 하면서 페이징 기법을 완성하는 것이다.

 

그러면 어떻게 가상 메모리의 페이지를 물리 메모리에 올리고 이것들을 어떻게 관리하는지 알아보자.

먼저, 페이지가 물리 메모리에 올라가야하는 상황이 됐다면 운영체제는 빈 공간(프레임) 리스트를 유지하고 있어야하고 이 리스트에서 하나는 선택하여 그 프레임에 페이지를 올리면 된다.

그리고 가상 메모리의 각 페이지에 대한 물리 메모리 상의 위치를 기록해둬야하므로 운영체제는 프로세스마다 페이지 테이블이라는 자료구조를 유지한다.

페이지 테이블의 주요 역할은 가상 메모리의 페이지 주소 변환 정보를 저장하는 것이다.

 

여기서 알아두어야 할 중요한 점은 각 프로세스마다 페이지 테이블이 존재하는 것이고 페이지 테이블을 통해 각 페이지가 저장된 물리 메모리의 위치가 어디인지 알려준다는 것이다.

 

 

 

 

2. 주소 변환은 어떻게?

그러면 이제 가상 주소를 어떻게 물리 주소로 바꾸는지가 궁금하다.

변환을 위해서는 가상 주소를 가상 페이지 번호(Virtual Page Number, VPN)와 페이지 내의 오프셋(offset) 2개의 구성 요소로 분할한다.

가상 메모리의 크기가 64바이트라고 가정하고 간단한 예시를 들며 주소 변환과정을 알아보자.

64바이트라면 가상 주소는 6비트(64 = 2^6)가 필요하고 페이지의 크기가 16바이트라고 했을 때 총 4개의 페이지가 나오므로 이 페이지들에 넘버링을 하고 이를 가상 페이지 번호로 표현하기 위해 6비트 중 상위 2비트를 가상 페이지 번호로 사용한다.

그러면 남은 4비트로 offset을 표현하게 된다.

오프셋(offset)은 우리가 페이지 내에서 원하는 바이트의 위치를 나타낸다.

 

예시를 들어 잘 이해했는지 알아보자.

64바이트의 가상 메모리 공간, 페이지의 크기는 16바이트이고 가상 주소(10진수)는 21일 때 VPN과 오프셋을 구해보자.

21을 2진수로 변환하면 010101이다.

여기서 상위 2비트는 VPN을 나타낸다고 했으므로 VPN은 1이고 오프셋은 0101, 8번째 바이트가 된다.

즉, 1번 페이지의 8번째 바이트가 가상 주소가 가리키는 곳이다.

 

이제 가상 주소를 통해 VPN과 offset을 얻는 과정을 알게되었고 이 정보로 물리주소를 얻는 과정을 알아보자.

위에서 구한 VPN을 가지고 페이지 테이블의 인덱스로 사용하여 어느 물리 프레임에 저장되어 있는지 찾을 수 있다.

즉, 페이지 1번이라고 한다면 페이지 테이블의 1번 인덱스에 저장된 정보가 물리 프레임이라는 것이다.

여기서 오프셋은 어떻게 될까?

정답은 오프셋은 절대 변하지 않는다는 것이다. 즉, 가상 주소의 offset과 물리 주소의 offset은 같다는 것.

 

이렇게 얻은 물리 프레임번호와 offset을 합쳐(물레 프레임 번호 + offset) 물리 주소를 구할 수 있는 것이다.

그러면 이제 궁금한 것은 가장 중요한 페이지 테이블은 어디에 저장되는가이다.

 

 

 

 

3. 페이지 테이블은 어디에 있을까?

위에서 예시로 든 64바이트 주소 공간, 4개의 페이지를 생각했을 때에는 페이지 테이블이 그렇게 크지 않다.

하지만, 우리는 64비트 주소체계를 사용하고 있고 프로그램의 용량은 매우 커지고 그렇게 되면 주소 공간의 크기도 64바이트가 아닌 몇GB를 주어야할 것이다.

몇GB라고 생각하고 페이지 크기를 보통 4KB로 설정한다고들 하는데 그러면 엄청난 페이지가 존재할테고 페이지 테이블은 그만큼 커질 것이다.

 

일단은 Three easy peices에서는 커널 영역의 메모리에 저장된다고 가정을 했다.

지금은 설명이 자세히 나와있지는 않지만 내 생각은 커널영역도 프로세스의 가상 메모리 상에서는 페이지로 나뉘어져있고 page table이 커널 영역에 있을 수도 있고 없을 수도 있고 없다면 swap disk에서 swap in을 해주고 물리 메모리에서 빠져야한다면 swap out해주지 않을까싶다.

커널영역이라고 무한대의 영역을 가질 수 없고 제한된 영역에서 많은 정보들을 담고 있을텐데 이러한 기법없이는 관리가 되지 않을 것이다.

 

 

---

[오늘의 나는 어땠을까?]

오늘은 운영체제 공부를 위한 시간보다는 이제 곧 있으면 나만의 무기를 만들 시간이 다가오고 프론트엔드, 백엔드 중 어떠한 역할을 맡을지에 대한 고민을 해보기위해 여러 영상과 자료를 보았다.

내가 이 블로그를 쓰기 시간한 첫 날에 생활코딩의 JAVA강의를 듣기 시작하면서 아래와 같은 문장을 남긴 적이 있다.

'백엔드 개발자가 되기 위해 대다수의 기업이 사용하는 JAVA를 공부하려고 한다.'

 

많은 생각과 고민을 한 끝에 개발자가 되고 싶다는 꿈을 가지고 개발자는 어떠한 일을 하는지를 보았을 때 나는 백엔드가 더 내게 맞다는 생각이 들어 진로방향을 정했다.

하지만 이제 정말 개발자의 커리어가 시작할 수 있다는 생각이 들고 다시 고민이 들기 시작했다.

프론트엔드는 유저에게 직접적으로 보여주는, 유저와 밀접한 소통을 할 수 있는 면에서 얼마나 유저에게 좋은 경험, 편리한 기능을 위한 화면 구성 등 고민거리가 재밌다라는 생각이 들었다.

백엔드는 유저에게는 보이지 않지만 서버, DB, 통신과정 등 나의 전공(정보통신학)과도 유사한 부분이 존재하고 서버단의 설계과정이 재밌겠다라는 생각이 들었다.

 

결론적으로 오늘 많은 자료를 보면서 백엔드가 나에게 맞다라고 확신을 세웠다.

프론트도 정말 좋은 포지션이고 백엔드에서 느낄 수 없는 재미를 느낄 수 있지만 백엔드에서의 설계과정이 너무나 궁금하고 알면 알수록 신기하고 내가 직접 개발하고 싶다는 생각이 들었다.

 

운영체제 주여서 이러한 시간을 가지는 것이 알맞지 않다고 생각이 들었지만 지금 몇 시간을 투자하여 방향을 정하는 것도 나쁘지않고 이제 다시 운영체제에 푹 빠져 주차를 보낼 생각이다.