[SW 정글 77일차] 기존 페이징 기법의 문제 해결하기

오늘은 어제 알아본 paging기법의 속도 개선과 공간복잡도를 개선하기 위한 방법들에 대해 공부했다.

그리고 저녁을 먹고서 project 3에서 해결해야할 과제를 읽어보고 코드를 봤는데 아직은 감이 잡히지 않는다.

그래도 해낼 것이다.

 

 

 

 

1. TLB부터 알아보자.

어제 알아본 페이징 기법은 가상 메모리를 고정된 크기로 나눈 페이지를 실제 물리 메모리에 저장해야하고 이를 매핑하기 위해 필요한 정보를 페이지 테이블이라는 자료구조에서 얻는다.

페이지 테이블은 물리 메모리의 한 부분을 차지해야하고 이는 큰 메모리 공간이 요구될 수 있다.

일단은 공간적인 문제를 생각하기 전에 주소 변환을 위해 페이지 테이블 정보를 읽는 것을 중점으로 두어 생각해보자.

가상 주소를 물리 주소로 바꾸기 위해서는 페이지 테이블에 있는 정보를 읽어야하고 페이지 테이블 접근을 위한 메모리 읽기 작업은 성능 저하를 유발할 수 있다.

페이지 테이블이 항상 물리 메모리에 상주하는 것도 아니여서 swap in/ swap out작업이 추가로 이루어져야할 수 있고 메모리에 올라왔더라도 이를 읽어들이는 작업이 필요하기에 시간복잡도가 증가할 수 있고 이 때문에 성능 저하가 유발될 수 있다.

 

이를 개선하기 위해 운영체제나 하드웨어의 도움을 받아야하고 그래서 TLB라는 것이 도입됐다.

TLB는 가상 주소를 물리 주소로 변환하는 과정에서 도움을 주는 MMU라는 하드웨어의 일부이다.

TLB의 역할을 간단히 말하면 가상 주소를 물리 주소로 변화하는 정보를 저장하는 하드웨어 캐시이다.

 

TLB가 도입되면서 주소 변환 과정이 어떻게 바뀌었을까?

먼저 가상 주소에서 가상 페이지 번호(VPN)을 추출한 후에 해당 VPN의 TLB에 해당 VPN을 PFN으로 바꿀 수 있는 정보가 있는지 확인한다.

만약 존재한다면 해당 TLB 항목에서 페이지 프레임 번호를 추출할 수 있고 해당 페이지에 대한 접근 권한 검사가 성공하면 그 정보를 가상 주소의 오프셋과 합쳐 원하는 물리 주소를 얻을 수 있다.

 

존재하지 않는다면 변환 정보를 찾기 위해서 페이지 테이블에 접근하고 가상 메모리 참조가 유효하고 접근 가능하다면 해당 변화 정보를 TLB로 읽어들인다.

 

여기서 알 수 있는 것은 TLB에 원하는 정보가 없어 TLB 미스가 많이 발생할수록 메모리 접근 횟수가 많아지고 이는 비용이 증가하게 하는 악영향을 끼치고 성능이 저하될 수 있다.

TLB가 속도를 개선시킬 수 있는 이유는 프로세싱 코어와 가까운 곳에 위치해 있고 매우 빠른 하드웨어로 구성되어있기 때문이다.

그리고 원하는 정보를 찾을 때 병렬로 접근하기 때문에 페이지 테이블을 읽어서 찾는 것보다 빠르다.

 

TLB의 구성요소는 VPN | PFN | 기타 의미를 가지는 비트들 이다.

기타 의미를 가지는 비트들에는 아래와 같은 것들이 존재한다.

- valid bit: 특정 항목이 유효한 변환 정보를 갖고 있는지에 대한 여부

- protection bit: 페이지가 어떻게 접근될 수 있는지를 나타냄 (읽기/ 쓰기/ 실행)

- address space identifier(ASID): 프로세스 식별자(PID)와 유사한 것으로 해당 정보가 어떠한 프로세스의 정보인지를 알려주어 프로세스들이 TLB의 공간을 공유할 수 있게 해줌

 

 

 

 

2. 페이지 테이블의 크기로 인한 문제를 해결하자

페이지 테이블은 얼마나 커질지 가늠을 할 수 있을까?

기존의 페이징 기법에서 얘기했듯이 하나의 페이지 테이블을 이용한다고 생각하고 32비트 주소체계와 페이지의 크기는 4kb라고 가정해보자.

그러면 주소 공간에는 2^32 / 2^12 약 백만개의 페이지가 존재할 것이고 페이지 테이블 엔트리가 4kb라고 한다면 페이지 테이블의 크기는 4MB가 된다.

여기에 추가로 알아야할 것은 각 프로세스마다 자신의 페이지 테이블을 갖는다는 것이다.

프로세스가 여러 개 실행 중일수록 더 많은 메모리가 필요하다는 것이다.

이러한 엄청난 메모리 요구로 인한 부담을 해결해줄 방법을 모색해야한다.

 

1) 더 큰 크기의 페이지를 할당하자

페이지 테이블의 크기를 줄일 수 있는 가장 간단한 방법은 페이지 크기를 증가시키는 것이다.

위에서 페이지 크기를 4KB로 했는데 16KB로 했다고 생각해보자.

그렇게 된다면 페이지 테이블의 크기는 1/4로 줄어들어 1MB가 된다.

간단한 방법이여서 그런지 단점도 동반된다.

바로 내부 단편화가 증가한다는 것이다.

프로세스가 여러 페이지를 할당받았지만 할당받은 페이지의 일부분만 사용한다면 그만큼 내부 단편화가 커지는 것이고 메모리가 금방 고갈될 수 있다.

 

 

2) 페이징과 세그먼트 기법을 합친 하이브리드 기법

이 부분은 완벽히 이해하지는 못했다.

다시 공부해서 정리할 생각이다.

 

 

3) 멀티 레벨 페이지 테이블

아마 대부분의 운영체제가 채택하고 있는 방식이라고 생각한다.

PintOS에서도 4단계의 멀티 레벨 페이지 테이블을 사용 중이기도 하다.

오늘은 Three Easy Peices에서 two-level page table을 배웠는데 4-level page table을 이해하려면 조금 더 시간을 들여야 할 것같다.

간단히 말하면 기존의 페이지 테이블의 페이지 크기만큼 잘라서 여러 개의 페이지 테이블을 만드는 것이다.

그리고 이 여러 페이지 테이블들을 관리하는 페이지 딕셔너리를 만들어 더 작은 페이지 테이블로 똑같은 페이징 기법을 구현할 수 있는 것이다.

기존에는 큰 페이지 테이블 하나를 만들어야했다면 멀티 레벨 페이지 테이블은 유효한 페이지 테이블만 존재하면 되므로 공간적으로 크게 효율적이다.

 

---

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

오늘은 너무나도 피곤한 하루였다.

원래도 항상 일주일에 하루정도는 오늘과 같이 피곤함이 엄청나게 느껴졌지만 이번에는 더 많이 느껴졌다.

사실 토요일부터 피곤함이 느껴졌지만 그래도 버틸만한 수준이였고 피로를 풀기위해 추가적인 수면시간을 가지지 않았다.

그리고 일요일도 보통의 경우에 1~2시간정도 더 잠을 자는데 이번에는 일이 있어서 평소처럼 4시간 정도 잠을 잤다.

이게 스노우볼로 작용해서인지 오늘은 거의 수면상태에서 공부를 한 느낌이였다.

아침에 코테 문제를 풀고 졸음이 쏟아져서 30분정도 자고 공부를 했고 점심을 먹은 뒤에도 졸음이 쏟아져 계속 졸다가 3시정도에 정신을 차려 공부를 했다.

그리고 저녁을 먹고서도 스터디를 하는데 눈을 감고 있는 시간이 더 많았다.

이렇게 졸고나서 스터디가 끝나고는 컨디션이 돌아온 줄 알았지만 다시 피곤함이 몰려와 1시간 정도 휴게실에서 잤다.

그제서야 컨디션이 돌아왔고 집중을 하고 공부를 시작했다.

 

너무 무리하게 수면시간을 단축하고 피로를 풀어줄 여유를 주지 않은게 큰 악영향을 미친 것같다.

깨어있는 시간이 긴 것도 중요하지만 오늘처럼 하루의 절반을 컨디션이 좋지 않은 상태로 보내는 것은 옳지 않기에 적절한 피로를 풀기위한 타임을 내게 줘야할 것같다.