[운영체제 OS] TLB의 등장 - 페이지 테이블 성능 문제와 개선

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

안녕하세요~
양햄찌 블로그 주인장입니다
오늘은 오랜만에 운영체제 포스팅을 올려보려고 해요

저번 시간에 페이지 테이블까지 설명을 진행했던 것 같으니 이번에는 TLB에 대한 개념을 다뤄보려고 해요.
제 포스팅을 좀 본 분이면 아시다시피 저의 글은 FLOW가 중요합니다~~
앞의 목차를 통해서 사전 개념을 잡고 읽으시길 추천드려요

서론

우리의 소중한 자원 메모리를 100%에 가깝게 쓰기 위해서

각기 크기가 다른 프로세스를 동일 크기로 쪼개 올리는 페이징(PAGING)이라는 개념이 도입됐었죠~~?

 

이렇게 쪼개져있는 PAGE를 순서대로, LINEAR하게(일렬로) 실행할 수 있게 하도록!

페이지테이블(PAGE TABLE)이 필요하다는 것까지 설명을 했습니당. (요기까지가 알고 있어야 하는 내용)

첫번째로 실행되어야 하는게 어디에 저장되어있고,

이어서 실행되어야 하는게 두 번째 페이지가 어디에 저장되어 있고
이를 알려주는 게 PAGE TABLE이 하는일이고,

저번시간에 페이지테이블의 원리를 설명하면서 용어까지 설명을 진행했었죠~~~

(기억안나시는 분은 이전 포스팅 참고하고 오기!)

즉, 페이지테이블이 logical address를 physical address로 매핑해서 변환해주는데,

논리주소에 있는게 페이지(page), 물리주소에 있는게 프레임(frame)으로 불린다는 걸 설명했었고 

오프셋(offset)에 대해서도 얘기를 했어요.

마지막에 그런데~~~ 페이지 테이블에 성능 문제가 있더라 언급만 살짝하고 넘어갔었죠 ㅎㅎ
오늘은 그 이야기를 이어가보려고 합니다.

 

페이지의 크기, 페이지의 개수, 오프셋

지금 우리의 컴퓨터가 32bit 프로세서라면, 하나의 페이지는 보통 4KB라고 했었죠!

그럼 하나의 프로세스가 가질 수 있는 페이지의 최대 개수는 몇개일까요?

전체 주소 크기를 한 개의 페이지 크기로 나누면, 

전체에서 몇 개의 페이지를 넣을 수 있는지가 나오겠죠. 

페이지 개수

논리주소 공간이 2의 32승이고, page의 크기가 2의 12승 (4KB)라고 한다면,

페이지의 최대 개수는 2의 20승개가 될거예요.

즉 page number는 20bits로 표현할 수 있고, 오프셋은 12bits로 표현할 수 있는거~!

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

페이지 테이블의 문제점 - 크기!?

프로세스마다 페이지 테이블을 가집니다.

하나의 덩어리인 프로세스를 잘게 쪼갠게 페이지인데, 그 순서를 알려주는 테이블은 하나씩 꼭 있어야할거아네요~!

 

하나의 프로세스가 크기가 얼만지는 모르겠는데, 우리의 32bit 프로세서 CPU는 최대 2의 32승까지 가능한거고

대빵 큰 프로세스가 들어올 경우를 항상 염두해둬야 해요.

 

아까 바로 위에서 대빵 큰 프로세스가 들어올 경우 가능한 최대 페이지 개수가 2의 20승개라고 했었죠?

즉 하나의 프로세스에서 2의 20개의 page를 구분할 수 있어야 한다면 대략 페이지 테이블이 4MB를 차지하게 됩니다.

하나의 프로세스의 페이지테이블이 4MB라 가정한다면

프로세스가 10개 돌아간다하면,, 40MB ㄷㄷ?? 용량무엇?!

아니! 프로세스 무게도 아니고 구냥 page가 순서대로 잘 실행되게 도와주는 것 뿐인데 이렇게 많이 잡아먹는다고?!!
딱봐도 성능 문제가 있죠!

최악의 경우를 대비해라!

그럼 이렇게 의문을 가지는 사람들도 있을거예요. 모든 프로세스가 다 그렇게 무겁지 않잖아요! 어떤 프로세스가 2의 32만큼 돌겠어요! 

네. 맞습니당. 최대 이만큼 있는거고 모든 프로세스가 그만큼 있는건 아니죠.

하지만 우리는 만에 하나를 대비해야해요.

 

게임은 프로세스크기가 크다

예를 들어, 여러분이 실행하는 프로그램 중에 메모장 이런거는 페이지 하나만 가지고도 실행 될 수가 있는 가벼운 프로그램인거고~ 아마 여러분이 실행하는 프로그램 중에 제일 덩치가 큰 게 게임일 텐데, 게임은 몇 백 메가의 주소가 있어야지 돌아가는 그런 프로그램일테죠.

이렇게 오래 걸린다건 실제로 실행 파일이 크기도 크고, 그거를 하드디스크에서 다 읽어가지고 메모리에 읽어 실행할 준비를 하는데 시간이 오래 걸리는거예요.

프로세스의 메모리 크기가 프로세스마다 다 다를텐데 운영체제는 일단 최대를 가정하고 준비를 해야 하겠죠. 괜히 작게 준비했다가 큰게 오면 큰일나니까요 ㅎㅎ

반응형

★ 잠깐?! 왜 4MB?
자 PAGE가 2의 20승개인데 이 페이지가 어디 프레임에 해당하는지 매핑해줘야하니까,,

결국 2의 20승개의 페이지를 매핑해주는 페이지 테이블이 있어야할거고...
페이지 테이블엔 2의 20승개의 페이지 정보가 들어가있을 테니까 1MB를 차지하죠. (2의 10승이 KB, 2의 20승이 MB)
근데 PAGE0, PAGE1, PAGE2 이처럼 PAGE 번호는 숫자로 표현되니까, integer타입이니 4byte를 차지할거고 그럼 1*4 = 4MB!
즉 페이지 정보를 담고 있는 페이지 테이블을 표현하기 위해서는 대략적으로 크기가 4MB가 필요하다. 그것도 프로세스 하나당!!

내 컴퓨터에 프로세스가 10개가 있어. 그럼 페이지 테이블이 4매가 짜리가 10개가 있어야 하는거죠.
즉 40메가 바이트가 있어야 하고, 100개가 있으면 400메가 바이트가 있어야합니다.
실제 여러분들이 사용하는 컴퓨터의 메모리가 충분히 커야지 많은 프로세스가 돌아가는거죠.
서버 같은 경우에는 훨씬 더 많은 메모리가 있어야지 성능에 큰 문제가 없이 돌아간다는 거고...

ㅎㄷㄷ한 메모리 크기, 요게 바로 페이지 테이블의 문제라는거~~

 

PAGE TABLE 문제점 - 속도!

자, PAGE TABLE을 어디에 저장해야 빠르게 참조해서 주소 변환을 시킬 수 있을까요??

당연히 CPU 내에 있는 MMU에다가 넣어야 속도가 빨라지겠죠? (MMU가 모르는 분은 이전 포스팅 참고)
근데 MMU에다가 4메가바이트 메모리를 집어넣는다..? 이건 불가능합니다. 엄청 비싸져요.
결국 CPU에 둘 수가 없으니까 램에 둘수밖에 없어요.

RAM에 둔다.. 이게 무슨말이냐.
지금 data라고 하는 번지 메모리에다가 10을 쓰기 위해
메모리에 있는 page table을 갔다와서 메모리에다가 데이터를 써야하는겁니다.
즉 메모리를 1번 접근하기 위해서 메모리를 2번 접근해야하는거죠. 

▶비효율적이다.

MMU 링크 https://jhnyang.tistory.com/247

예전에 배웠던 contiguous allocation은 더하기만 하면 되었잖아요!!
MMU안에다가 더하기 로직만 넣으면 되니까 쉽게 전환이 됐는데,

그거는 메모리 효율이 나쁘다 그래서 페이징을 생각해냈는데....!

페이징이란 방법은 해당 페이지가 어느 프레임에 매핑되어 있는지 page table을 관리를 해야 하고..

또 그놈의 page table entry는 2의 20승 개수가 있어야 한단 말이죠.

4메가 바이트 페이지 테이블이 필요한데 이걸 CPU안에 넣을 수가 없으니 이젠 또 메모리에 둘 수밖에 없대.
메모리를 access하기 위해서 또 한 번 메모리를 access해야 하니까 성능이 두 배로 나빠진대...

(문제를 해결했더니 문제가 나오고 이를 해결했더니 또 문제가 나오는 골때리는 상황 ㅎㅎ)

어떻게 하면 문제를 해결할 수 있을까? CPU도 안돼, 메모리에 안돼, 어디서 해결을 해야할까요??

 

PAGE TABLE의 개선

사실 CPU의 MMU안에서 해결을 하면 좋겠죠. 그래야 성능이 두배로 나빠지는게 아닌게 되니까요.
그런데 4MB 메모리를 MMU안에서 해결을 하려고 하면 안된다했잖아요.
어떻게 해야 할까요?

사진출처:https://nsaira.com/what-is-cache-memory/

바로~~ 캐시메모리를 쓰는겁니다. 

(역시 조상들은 천재들이 분명해요)

실제 page table은 크기가 2의 20승 개나 있지만 실제로 이게 다 쓰이는건 아니잖아요. 대부분은 안 쓰는 영역이죠.

계산기

왜냐면 예를 들어 메모장은 실행 파일이 27킬로바이트 안쪽이예요. 그래서 사실 page가 10개까지도 필요가 없어요.

즉 2의 20승개 중에 7개만 쓰고 나머지는 다 안쓰는거예요.

근데 게임은 메모리를 많이쓰니까 많이 쓸 수 있겠죠?
예를 들어 최악의 경우는 다 쓸 수도 있을거예요.

다 필요하더라도 우리 프로그램 소프트웨어는 locality라는 특성을 가지고 있어서 자주 쓰이는 놈은 앞으로도 자주 쓰이고 한번 쓰이고 안쓰이는 놈은 앞으로도 안쓰일 확률이 큽니다.

그게 바로 캐시메모리를 쓰면 컴퓨터의 성능이 향상되는 가장 큰 이유로 이것도 결국 마찬가지 개념인거예요~ :)

실제로 참조되는 페이지는 이 중에 몇 개 안된다는 원리를 활용한거죠. 더군다나 page하나가 커버하는 영역이 4KB나 되잖아요. 페이지가 4KB니까 실제로 그 프로세스가 돌아갈 때 자주 사용되는 메모리 영역은 페이지 몇 개 면 됩니다. page 몇 개에 대한 정보를 MMU안에다가 캐시로 두고 사용을 하게 되면 MMU에서 바로 사용이 가능해요. 이러면 속도도 OK 크기도 OK. 그런 캐시를 뭐라고 부르냐면 ~~~~ translation lookaside buffer 라고 합니다 ㅎㅎ 이게 바로 TLB예요 ㅎㅎ

마무리

오늘은 간단하게 TLB를 소개하는 시간을 가져봤어요
페이지 테이블의 어떤 점을 보완하기 위해 이러한 아이디어가 나왔는지, TLB는 무엇인지 간단히 얘기해봤는데요
다음에는 이 TLB에 대해 좀 더 깊이 들어가보도록 할게요.

운영체제 책 어떤걸 참조하셨냐고 여쭤보시는 분들이 꽤 계신대, 전 공룡전공책이랑 대학강의 그리고 스스로 구글링등을 통해 지식을 얻었을 뿐 그 외의 책을 별도로 참고하지는 않았습니다.

포스팅 글의 저작권은 저에게 있으닝 함부로 무단도용하지 말아주세요 :)
도움이 되셨다면 공감과 댓글은 큰 힘이 됩니다. 파이팅~~~~