[운영체제OS] 페이지 테이블이란? Page Table 원리와 역할

[운영체제 완전정복 목차]

안녕하세요 양햄찌 블로그 주인장입니다.ㅎㅎ

오랜만에 운영체제 포스팅을들고 왔어요.

 

지난 포스팅에서 페이징이 왜 생겼는지, 페이징은 무엇인지에 대해 알아보셨는데요,

PAGING개념은 꼭 선행학습이 있어야 하므로 아직 개념이 확실치 않으시 독자분께서는 아래 포스팅을 선독 하시기를 추천드려요~!

 

페이징과 내부 단편화란: jhnyang.tistory.com/290

[운영체제 OS] 메모리 관리기법 - 페이징 (paging)이란? 내부 단편화(Internal Fragmentatoin)에 대해 알아

서론

페이징테이블에 들어가기 전에 지금까지 다뤄왔던 FLOW를 정리해봅시다.

우리는 현재 메모리 관리기법 파트에 대해 다루고 있어요.

기존의 방식이었던 contiguous allocation (연속할당)방식은 치명적인 외부 단편화 문제를 발생시켰고, 

이러한 문제를 잡기 위해 메모리를 동일한 크기인 page로 쪼개는 방법이 나오게 되었죠. 

중요 자원인 메모리를 이제 거의 100%에 가깝게 사용할 수 있게 되는 건 좋은데, 메모리 적재가 연속적이지 않고 여기에 있다 저기에 있다 흩어져있으니 프로그램을 수행하는데 문제가 발생하겠겠죠?!

이렇게 조각조각난 page들을 문제없이 수행하기 위해, 즉 linear(일직선, 선행적)으로 쭉 수행시켜줄 수 있도록 도와주기 위해, page table이라는게 있다!! 이렇게 예고하면서 저번 시간에 포스팅을 마무리 지었었어요. ㅎㅎ

오늘은 이 page table이 어떻게 구성되어 있으며, 어떤 원리로 동작해 이 문제를 해결할 수 있었는지 이야기를 진행해보려고 해요.

페이지 테이블 역할

서론에서 정리했던 페이지 테이블 개념을 좀 더 도식화해봤어요.

자, 수행하려는 프로세스가 메이플스토리, 유튜브 이렇게 두 개 있다고 가정합시다.

유튜브 프로세스를 동일한 크기인 페이지 3개로 나눴어요. 

하지만 수행될 때에는 당연히 page 0부터 page 1, page 2 이렇게 순차적으로 실행되어야 이상 없이 프로세스가 동작하겠죠?

 

결국 프로세스가 메모리에 올라가도 순차적으로 수행되어야 하는 건 똑같은데,, 

page 방법론에서는 메모리에 적재된 page 들을 순차적으로 수행하면 

'메이플스토리 page2-> 우투브재생 page1 -> 메이플스토리 page0 -> 유투브제생 page 1'순이 되어버리니까 당연히 하나의 프로세스가 정상적으로 수행되지 않겠죠!

 

즉 유튜브page0 다음에는 유튜브page1이 연달아 실행될 수 있도록, 페이지 테이블이 순서에 맞는 물리적메모리 위치를 찾아줍니다.

또 메이플스토리도 마찬가지로 순차적으로 실행될 수 있도록 메이플스토리의 페이지 테이블이 있어요.

즉 프로세스마다 페이지테이블을 가지고 있는 것이죠~

페이지 테이블(page table)의 구조 

페이지테이블의 원리를 초점으로 보자면 이게 다입니다~ 쉽죠?!

위의 그림의 페이지테이블을 봅시다. page0은 frame1에 있음을, page1은 frame4에, page2는 frame3, page3은 frame7에 있음을 페이지테이블이 알려주고 있어요.

 

결국 페이지 테이블은 배열과 같습니다.

배열처럼, 인덱스가 페이지 번호를 가르키고 그 배열에 담고 있는 숫자가 매핑할 프레임 번호인 것이죠.

 

출처: Page Table Entries in Page Table - GeeksforGeeks

사실 위 그림은 page table의 가장 핵심을 설명하기 위해 간단화(?)한 구조였고

실제 페이지 테이블은 페이지번호와 프레임 번호 외에도, 여러 편리 기능을 위해 이처럼 다양한 필드들로 구성되어있습니다. 

페이지(PAGE)의 크기와 논리적 주소 구성 

사실 논리적 주소가 물리적 메모리에 적재되어 물리적 주소에 매핑되는거잖아요/

이전 포스팅에서 CPU에 의해서 생성되는 주소체계를 보통 논리적 주소라고 하고 RAM에 실질적으로 로드되는 주소를 물리적 주소라고 설명했었어요.

 

페이지 매핑에 맞춰 CPU로부터 생성되는 논리적 주소는

페이지번호와 페이지오프셋으로 구성되어 있습니다. 

◆ 페이지 번호

위에 쭉 설명했듯이 매핑을 위해, page와 frame은 번호를 갖습니다. page0 할 때 이 순서에 해당하는 숫자 '0'이 번호인거죠! 논리메모리를 자른 것은 page라 하니까 논리주소는 페이지번호를 포함하고 있습니다.

참고로 논리메모리를 자른 페이지를 셀 때에는 page number라고 하고 물리메모리를 자른 프레임을 셀 때에는 frame number라고 합니다. 하지만 덩어리인 page만으로는 정확한 주소를 표기할 수 없어요. 이를 위해 오프셋이 있습니다.

 

[참고] 페이지 크기 

The idea behind virtual memory is that physical memory is divided into fixed size pages. Pages are typically 512 to 8192 bytes, with 4096 being a typical value

페이지 크기는 대게 512bytes에서 8192bytes까지 될 수 있는데, 4096bytes가 보통 전형적인 값입니다.

4096bytes이면 4×1024이므로 4KB이죠? 4KB는 2의 12승이므로 페이지 하나당 12bits를 차지합니다. 

 

◆ 페이지 오프셋

자 하나의 페이지가 4KB라고 가정합시다. 그러면 '페이지0'도 크기가 4KB이겠죠? 

'페이지0'은 결국 주소로 따지면 0번지에서 2의12승까지 값의 번지까지 있는거죠. 

그렇게 해서 page번호 말고! page내의 번호를 우리가 offset이라고 부릅니다.

 

결국 page0의 0번 오프셋이라 하면 2의12승 위치의 논리주소가 되는거고

page1의 0번 오프셋이라 하면 2의 13번지에 위치한 주소를 가리키는거죠

 

page번호를 p라고 표현하면 이 페이지 내에서 주소 위치를 나타내는 오프셋을 d라고 불러요.

즉 logical address의 정확한 위치가 p하고 d로 표현이 되는거죠~

하나의 프로세스가 가질 수 있는 최대 크기

만약 내가 사용하고 있는 운영체제가 32비트 프로세서라 가정하고 페이지 크기가 4KB라고 가정하면 

한 번에 CPU가 2의 20승 개수의 페이지번호를 구분할 수 있어요. 

2의 20개 이상의 페이지일 경우 32bit를 넘어가기 때문에 표현할 수 없죠.

 

즉 32비트 프로세서일 때 하나의 프로세스가 가질 수 있는 logical address 전체 크기는 2의 32승, 페이지의 최대 개수는 2의 20승이 되는거죠!!

2의 32승은 4GB

32bit프로세서에서는 프로세스 하나의 크기가 4기가를 넘으면 안되는거죠~~.

근데 4기가짜리 프로세스는 사실 없지만 32bit processor는 논리적으로는 4기가까지가 가능하다는 것~

논리주소 물리주소 변환 FLOW

여기까지 다 읽으셨다면 위의 그림이 이해가 될 거예요!!

위 사진에서 p은 페이지번호(PageNumber)이고 f은 프레임번호(FrameNumber)입니다. d는 페이지 오프셋이예요

 

논리메모리 앞 20bits에서 페이지 번호를 페이지테이블에서 검색하면 프레임번호가 나오겠죠!

page의 크기하고 frame의 크기는 똑같잖아요. 그러니까 offset은 똑같이 가면 되는거죠.

page로 쪼개놓았어도 이런 방식으로 논리주소를 물리주소로 매핑할 수 있는거랍니다.

즉 논리메모리에서 p페이지의 d오프셋 위치는 f프레임의 d에 적재되어있다는 것~!

다음 포스팅 TLB 예고

자, 지금까지 제가 설명했던 것을 한번 정리해볼게요~~~

logical address를 physical address로 translation을 하는데, 요 해당 page번호에 해당하는 frame 번호를 관리하고 있는 page table을 뒀었죠. 이 page table은 프로세스마다 하나씩 있어야겠죠? 그래야 프로세스 번호 0,1,2,3 등이 있을거잖아요. 그 다음에 프로세스가 만약에 바뀌면 이 page table은 해당 프로세스의 page table바꿔서 관리를 해야 하는거죠!!

 

자 그런데!!!! 이 page table의 크기가 얼마일까 생각을 해보면 지금 page는 32bit라고 가정을 했을 때 2의 12bit라고 했으니까... 하나의 프로세스는 2의 20bit의 page가 있는거죠. 2의 20비트면 무려.. 1메가입니다

그런데 페이지테이블은 숫자를 저장하고 있으니 integer 4바이트 곱하면 4메가이고..

프로세스가 10개만 되도 40메가... 넵 page table만 사용하기엔 성능 문제가 있습니다. 이를 해결하는 녀석이 TLB예요. 이는 다음 포스팅에서 이어 진행하도록 할게요~

 

도움이 되셨다면 수줍은 방문객들은 공감,

고마움을 전하고 싶다면 댓글과 광고클릭으로~!

언제나 여러분들의 응원과 칭찬은 작성자에게 큰 동기부여가 됩니다. 다음 포스팅에서 또 봐요.