[pintOS] frame와 page, SPT와 프레임 테이블

vm을 미리 예습하면서 헷갈렸던 개념들이 여럿 있어서 정리해둔다

먼저, 우리의 핀토스는 qemu라는 에뮬레이터 위에서 작동한다

따라서 작동할 때 사용할 최대 메모리 크기를 고정하고, 파일 기반의 가상 디스크 이미지를 만들어 사용한다

고정한 물리 메모리는 유저 풀과 커널 풀로 나뉘어서 사용되고, 프레임과 페이지는 유저 풀에서만 할당받을 수 있다.

그럼 커널 풀은 어디에 쓰이나? 커널 스택이 바로 이 커널 풀에서 생성되는 것이다.

 

프레임과 페이지

그럼 대체 프레임과 페이지가 뭐가 다른것이냐? 우리는 가상 메모리를 배울 때 가상 주소와 물리 주소가 있다는 것을 배웠다. 유저 프로그램은 가상 주소를 통해서 필요한 데이터를 요구하고, CPU는 이를 물리 주소로 번역해서 실제 데이터를 찾아서 반환해준다.

핀토스 내에서 프레임은 물리 주소에 존재하는 실제 데이터를 담은 4KB 공간이고, 페이지는 실제 물리 주소를 가리키고, 제어 비트를 엔트리에 담고 있는 논리적 공간인 것이다.

하지만 이를 vm 과제에 그대로 대입해서 생각하면 안된다...

vm 과제에서는 frame 구조체와 page 구조체 두개가 있는데, 이를 확인해보자.

struct page
{
    const struct page_operations *operations;
    void *va;			 /* 사용자 공간 기준의 주소 */
    struct frame *frame; /* frame에 대한 역참조 */

    /* 구현에 필요한 부분 */

    /* 타입별 데이터는 union에 바인딩됩니다.
     * 각 함수는 현재 union을 자동으로 감지합니다. */
    union
    {
        struct uninit_page uninit;
        struct anon_page anon;
        struct file_page file;
#ifdef EFILESYS
        struct page_cache page_cache;
#endif
    };
};

이 구조체 내의 va가 바로 가상 주소를 나타내는 것이다. 그럼 우리가 배운대로 페이지 테이블에 이 페이지 구조체가 리스트나 해시맵으로 있는건가? 그건 아니다.. 나는 이 부분이 너무 헷갈려서 시간을 낭비했다. 페이지 테이블에는 단지 실제 물리 주소 36비트(12비트는 오프셋)와 여러 제어 비트로 이루어진 페이지 엔트리만이 집합으로 있을 뿐이다.

프레임 구조체도 한번 보자

struct frame
{
	void *kva;
	struct page *page;
};

여기에 필드로 있는 kva는 뭘까? 커널 가상 주소, 즉 물리 주소이다. 근데 물리 주소만 담겨있고, 실제 데이터는 하나도 담겨있지 않다. 아마 저 kva에 접근해서 데이터를 사용하지 않을까? 하는 추측이다

그럼 위 구조체들은 대체 어디서 사용하냐? 이제 SPT를 보자

SPT

/* 현재 프로세스의 메모리 공간을 나타냅니다.
 * 이 구조체에 대해 특정 설계를 강제하지 않습니다.
 * 모든 설계는 여러분에게 달려 있습니다. */
struct supplemental_page_table
{
};

이런 젠장 아무것도 없다. 사실 vm 과제에서는 이렇게 텅텅 비어있는 함수가 굉장히 많다. 그래서 보고 흐름을 따라가는 것도 꽤 시간이 걸린다

일단 SPT, 그러니까 보조 테이블은 사실 정말로 처음 듣는 개념이다. CSAPP에서도 본적이 없고, 공룡책에서도 못 본 것 같다
천천히 개념부터 알아가보자

먼저 요구 페이징 기법에 대해 알아야 한다. 요구 페이징 기법은 처음 프로세스의 페이지들을 로드할 때 물리 메모리에 해당 페이지를 먼저 적재하지 않고, 로드 이후 처음 접근할 때 비로소 해당 페이지를 적재하는 기법이다.

따라서 처음 접근하는 페이지는 무조건 페이지 폴트가 발생하고, 페이지 폴트가 발생한 페이지가 유효한 주소인지 판단하고, 적절한 물리 페이지를 반환해주는 것이다.

그런데 여기서 해당 페이지가 적절한 주소인지는 어떻게 알까? 또한 적절한 물리 페이지는 또 어떻게 반환해 줄 것인가?

페이지 테이블의 엔트리에 저장해두면 아닌가? 싶지만... PTE는 64비트밖에 되지 않는다. 이 많은 정보를 어디에 담아둘 것인가?

 

사실 SPT에 대한 정보가 부족해서 추측이 정확하지는 않지만.. 코드를 까보고 GPT와 열심히 토론한 결과 아마 위 페이지 구조체를 통해 메타데이터를 저장하고, 이 페이지 구조체들을 SPT에 저장해서, 페이지 폴트 시에 SPT에서 폴트가 발생한 페이지를 찾아 실제 물리 데이터를 찾아 적재해주는 것이 아닌가 생각하고 있다.

 

그래 SPT는 알겠어. 그런데 프레임 테이블은 대체 어디에 사용되는건가?

프레임 테이블

프레임 테이블 관리?? 그럼 코드 상에 frame_table 구조체 정도는 있어야 하는거 아닌가? 그런데 아무것도 없다. 위 SPT처럼 구조체만 있고 속이 텅 비어있는 것도 아니고 그냥 구조체 자체가 없다... 이게 뭐지??

위 코드에서 보면 프레임과 페이지는 일대일로 매핑되어 있다. 그럼 사실 프레임은 SPT를 통해 관리될 수 있는거 아닌가? 이러한 의문이 들어 조교님에게 질문을 했다.

나는 정말 굳이 프레임 테이블을 구현해두지 않아도 프레임을 추적할수 있을 것 같은데 왜 과제 설명서에서는 구현해두라고 나와있는지 알수가 없었다... 이에 대한 조교님의 답변은

결론은 효율적인 CPU의 디자인 때문이라고 한다.. 하드웨어의 효율성 때문이라니 납득하고 넘어갈수 밖에 없었다 ㅠ

 

다음에는 요구 페이징 기법을 핀토스에서 어떻게 구현하라고 뼈대를 짜 두었는지, 아니면 객체지향을 C에서 어떻게 구현해두었는지 둘 중 하나를 포스팅하겠다.