멀티레벨 페이지 테이블과 하이브리드 접근

시험범위는 오늘 배우는 것까지 나오고요. 스몰러 테이블을 오늘 다 할 수 있을지 모르겠는데 하는 데까지 한번 해볼게요. 그리고 지난 시간에 무변을 두찬 기교하고 넘어가는 데 또 다른 질문이 있나요? 시험이나 무변을?

아무거나 해주세요. 없어요? 아무거나 물어봐주세요. 시험이 어려운지 쉬운지는 모르겠어요. 제가 여러분들이 그걸 쉽게 느낄지 안 느낄지를 모르기 때문에 수업시간에 배울 걸로 제가 맛 한 걸로 출제를 하려고 하고 물어보려고 합니다. 응.

그렇기 때문에 아마 여러분들이 수업을 열심히 해주셨다면 저는 다 풀지 않을까 생각하고 여러분들이 모두 백정을 받으면 어떻게 할지 이런 부적을 하는 데는 최종일이거든요. 작년에 보니까 그러진 않아가지고 그런 걱정이지 않았는데 더 쉬울 것 같아요. 아직 문제를 다 내지 못했을 때 그런 것 같고

질문 없으면 바로 가요. 질문 4. 아 맞아. 그게 알려줘야 되는데. 그래서 제가 그 그 감기실 4개인가 5개를 받았어요. 그 시험 시간에. 그래서 제가 여러분들을 배분을 해야 되거든요. 그래서 그거 나눈 다음에 이 캠퍼스에 올려줄게요. 그래서 공지사항을 올려서 여러분들 뭐 문자 같은 거 가져. 그래서 제가 거기다 올리면 여러분들 알 수 있게 교체를 할 수 있어요. 거기다 여러분 학번이나 단속 이렇게 랩핑 해가지고 거기다 올려볼게요.

그래서 너무 많아서 이게 잘 될지는 모르겠네요. 좀 걱정은 되는데 한 번만 생각해볼게요. 시험 시간은 확정은 아닌데 여유롭게 생각을 하고 오세요. 왜냐하면 상당히 너무 많아서 중간에 문제가 발생할 수도 있을 것 같아서 조금 그 문제를 해결하기 위해서 예를 들어 뭐 사람이 특정 방위수에 몰려서 공기 자리가 부족한다라고 이런 문제가 발생할 수도 있을 것 같아서

그럴 때는 조금 조치가 필요할 수 있으니까 좀 딜레이 되는 것까지 생각을 하고 와주시면 감사하겠습니다. C코딩도 준비해야 되나? C코드 짠. 아! 코딩하는 거야? 네. - 송코딩. - 컷? 아, 송코딩. 송코딩. 송코딩.

사실 그 문제를 고민하고 있는데 어디까지 해야 할까 고민하고 있어요. 그렇다면 제가 생각을 안하고 있는 건 아니고 그렇다면 이거를 전부 철자 하나하나 다 외워서 그거를 해서 조금이라도 틀리면 틀리게 해야 되냐 그렇게 하고 싶지는 않고 그런 데서 약간 고민이 있습니다.

그 말은 제가 살짝 조금 틀린 것보다 의미적으로 그걸 만든 것을 더 중요하게 생각을 하기 때문에 그걸 위한 과학이 있을까를 궁금해서 보고 있어요. 무슨 말인지 알죠. 또 질문 있어요? 그러면 시작할게요.

그래서 지난 시간에 배운거 TLB, 이 친구는 앞에서 얘기했던 페이지 테이블이 매우 크기 때문에 그리고 페이지 테이블은 글쎄 얘기했는지 아닌지 모르겠는데 그 슬라이드는 있어요. 각각의 프로세트마다 페이지 테이블을 갖고 있어야 되겠죠.

예를 들어서 이 예제 분이 보면은 이 예제 분은 이 예제 분은 이 예제 분은 각각의 버터와 메모리는 존재한다고 우리가 얘기했고 각각의 버터와 메모리가 이 KB 테이블에 KB 테이블이 아니라 그 히컬 메모리에 매칭하는 이 과정이 각각 서로 서로 다르게 존재해야 될 거잖아요 그래서 이 때문에 이런 것들이 각각의 프로듀스마다 존재하고 있다 라는 건 여러분들이 알고 계셔야 되고

그리고 또 문제를 할 것들이. 뭐 그런 거 아닌가. 그래서 이 수게잇 테이블이 매우 크기 때문에 매우 크기 때문에 이런 부분들을 이 킬비를 통해 가지고 빠르게 내가 접근할 수 있는 하루에 캐시에 저장을 해놓고

아 그렇게 지장에 놓고 요거를 빠르게 해 놓고 있다 이 계획을 만들어주고 그 포즈 조그를 하려고 뭐 좀 차는 없었고 으 예 그래서 이 길에는 이 화소 로그니와 해프로 흔기를 우리가 보통 어 만드는 그 프로그램들이 이런 것을 어 안 좋고 싶다 때문에 요거를 이제 번제 폰으로 시일이 간 빠져 놓일 것이다 생각을 하고 맞는 거다 라고 그렇게 설명을 드렸고 그리고 여기가 특히 셀이 이스가 발생을 했을 때 요거의 구현을 할 것인가 그래서 과거에는 하길래가 이거 모든 것을 힐리 비스가 발생을 했을 때 캐이 그거 시스란 왜 요새가 라인 이거는 굉장히 간단한 해결이 있으니까 그걸 보면 그냥 되는 거니까 내가 추가로 볼 필요는 없는데 힐 미스 같은 경우에는 요가 좀 들이 필요하다 라는 거죠 뭐 얘기하고 있는 그 적절한 페이지를 페이지 테이블에 찾아오고 그거를 그거를 그거를 부터 이 잘 탈 수 메시장 이라고 하는 이 그 vpn 2 그 어떠한 그 페이지 페이지 넘어의 그 탈 수 있는지 그저 들어 정보들을 얘기하는 거죠 그게 그걸 뽑아야 되고 그러게 해야 되고 다시 그 힐이 억제이 단 다음에 는 그 적절한 수술한 걸어놓은 들을 하려가 한다

그러면은 이제 이 디스크로 보면은 그런 KB 미스 같은 거를 상생적으로 통해서 하는 쪽으로 이제 개선이 된다 이런 얘기를 말씀드렸고 그래서 뭐 두 번째 디에디 기준으로 이런 것들을 통해서 트랙을 하셔야겠습니다. 이런 거에 말씀드렸습니다. KB이 아프게디가 이렇게 생겼고 이런 건 필요한 게 아니라 이런 거에요. 그 페이지, 버추얼 페이지 넘버가 같은 이런 경우들을 구조하기 위해서 이 ASID가 필요하다 이런 것도 말씀드렸고 그리고 페이지 프레임 넘버 또 같은 경우가 있을 수 있다. 이것도 말씀드렸고 그래서 이 TLD도 이 크기가 정해져 있을 때 이 크기가 다 차면은 리플레이스먼트가 이루어져야 되는데 어떤 거를 리플레이스먼트 해야 되는지를 말씀을 드릴 때 이 LRU를 말씀드렸고 LRU는 가장 매너 최선에 활용한 것만 TAB에 남기겠다 이런 뜻이다. 이런 포리스다 라고 제가 말씀을 드렸는데 이 LRU를 여기서 어...

뭐지? 왜 이 LRU를 프로듀스로 활용을 하냐면 그 앞에서 얘기했던 그 로퀴리티 때문에 그런 겁니다. 정확하게. 왜냐하면 그 로퀴리티가 템프로 로퀴리티 스파셜 로퀴리티가 생기는데 그 로퀴리티를 기본적으로 만족한다고 우리가 생각하고 있을 때 그렇다는 것은 내가 템프로 로퀴리티 기준으로는 내가 최근에 썼던 것을 다시 걔를 활용할 가능성이 높다고 판단할 수가 있게 되는 거잖아요. 그래서 그런 장점들을 그대로 가지고 있는 것에 대해서 이 LRU를 활용하는 거다. 그렇게 생각을 하시면 됩니다. 예를 들어 활용하는 것을 생각을 했을 때.

그 얘기를 말씀드렸고, 뭐 여기까지 말씀드렸어요. 그래서 오늘은 스몰어, 스몰어 테이블에 대해서 말씀드리겠습니다. 네. 스몰어 테이블은 사실 뭐 별거 없어요. 별거 없고

패던이 계속 똑같이 반복하는 것 같아요. 문의드라는 것이라면 이런 것들 계속 말씀을 드렸던 이렇게 32bit address space라고 하면 이 address space의 크기가 2의 32등이라고 말씀을 드렸죠. 32만큼의 address를 갖는데 내가 4K짜리 페이지 2로 이루어져 있다고 하면 이렇게 나누면 이 페이지 수가 나온다고 말씀드렸고

이 페이지 테이블의 사이트를 내가 구한다면 페이지 테이블의 사이트는 페이지 테이블을 이렇게 구성이 되어있잖아요. 이런 식으로 내 2d array라고 생각을 했을 때 여기가 vpn의 수이고 여기가 vpn의 수이고 이거는 size of entry죠. size of entry죠.

사이더맨트이기 때문에 vtn 곱하기 vtn의 수 곱하기 사이더맨트 하면은 이 페이지 테이블의 키가 나와있죠. 그거를 또 밑에서 하고 있는거죠. 요게 vtn의 수인거고 그거 곱하기 요 4바이트가 사이더맨트 이니까 이거 두개 곱하면은 페이지 테이블의 사이더맨트 나오겠죠. 요 예제 기준으로는 페이지 테이블에 그 각각의 프로세스에 대한 페이지 테이블의 크기가 4배가가 나와있다 라는 것을 구할 수 있는데

얘는 크죠? 4세바가 있으면 꽤 크잖아요. 꽤 큽니다. 물론 지금은 얘가 크지 않다고 생각할 수 있는데 10년 전만 해도 꽤 컸을 거예요. 내 컴퓨터의 램이 크지 않았기 때문에. 근데 이거를 내가 줄이고 싶으면 어떻게 하면 될까요? 얘를 줄이고 싶어요. 그럼 뭘 하면 되죠?

요거를 줄이던가. 요거를 줄이면 되겠죠. 쉽게 하는 것은 페이지의 수를 줄이면 이 전체의 테이블 사이즈 크기가 줄어들겠죠. 피지컬 메모리가 그대로면 피지컬 메모리의 크기가 그대로라고 가정을 했을 때 옐로운 쪽에 있는 엔트리는 줄일 수 없잖아요. 옐로운은 줄일 수 없으니까

왜냐하면 여기 엔트리가 있는 그 피지컬 프레임 넘버 같은 경우에는 이거는 사실 앞에서도 우리가 했지만 피지컬 메모리의 크기에 따라서 이게 결정이 되잖아요 그렇기 때문에 얘를 줄일 수는 없어요. 그렇기 때문에 얘를 줄이고 줄어보는 겁니다. 이 전체의 개수를. 개수를 줄이려면 간단하게 이 페이지의 크기, 각 술로 바이트를 늘리면 되겠죠. 그렇게 한번 해보는 거예요. 그러면 일단 나눠는 이 크기가 늘어나니까 당연히 그 전체의 개수가 들어있죠. 그렇게 해보면 해보면 됩니다.

페이지들로 이루어진다고 하면 입병이 났는데 말할 때마다 죽겠어요. 하여튼 이게 내내가 늘었으니까 오늘 이 시리즈용으로 나눠주는 것을 이 시리즈용으로 나눠주고 있죠.

그러면 4MB로 4분의 1으로 줄었어요. 그런데 이렇게 늘리면 게수가 줄어서 페이지 테이블 키가 줄어들지 않냐 이렇게 얘기를 할 수 있는데, 이러면 어떤 문제가 발생하냐면, 여기서 얘기하는 인터넷 프레임면세이션이라는 이슈가 발생을 한다라고. 그래서 이게 본인적인 세일책이 아니다. 라는 얘기를 하고 싶었던 거예요. 그러니까 지금 제가 무슨 얘기를 하고 있는지 다시 짚고 넘어가면, 앞에 TAB가 나온 것도 이 페이지 테이블이 너무 크기 때문에 피지컬 메모리에 저장을 해놓고 이걸 막 하는 건데, 그럼 페이지 테이블을 조금 줄여가지고 이 메모리를 좀 효과적으로 쓰기도 하고,

페이지가 너무 크기 때문에 이런 크기를 줄여보고 싶다는 거고요. 그걸 줄이기 위해서 페이지 테이블의 사인을 줄이는 방법에 대해서 우리가 얘기를 했을 때 지금 가능한 방법은 그냥 이거 기준으로는 페이지 하나의 크기를 늘리면 전체 객수가 줄어든다. 그러므로서 각 테이블의 크기가 줄어든다. 그런데 이렇게 되면 인터넷 스테레이먼테이션의 이슈가 발생하기 때문에 본질적인 이슈가 생긴 책이 아니다. 라는 얘기까지 볼 거예요. 인터넷 프리그먼테이션은 뭐냐면은 우리가 앞에서 얘기했죠. 인터넷 프리그먼테이션은 얘기했죠. 인터넷 프리그먼테이션은 전체 메모리 크기가 파편하니까

이 써난은 왜 그래야 되잖아요 이 부분 말이라면은 우리 전체 피지컬 메모리가 그 프라이 베이전 파편화 됨으로써 그 내 몸이 연극된 뭔가를 할 따라가기 원 따라서 를 배경이구나 다시 앞에도 좀 돌아가면은 그 있었는 뜨거운 게 아니라 만들 때 이렇게 이게 시컬 메모리 라고 제가 말씀을 드릴 때 요건 간 내가 여기의 요정도 크기를 뭐

이 정도뿐이 나타나고 싶어요. 이 정도. 팔짱하고 싶으면 계속된 공간에다가. 그때 이렇게 예를 들어 얘가 되게. 이걸 버릴게요. 이렇게 되게 턱 편하게 되어 있어요. 이렇게. 이렇게 막 턱 편하게 되어 있습니다. 막 팔짱은 되어 있는데 중간중간에 막 막 고목이 뚫려 있어서 이게 한 번에 못 들어가요. 이런 경우는 우리가 있어서 프레그리테이션이라고 얘기했잖아요. 인터장 프레그리테이션은 뭐냐면은 내부에 턱 편하가 발생했다는 거겠죠. 그 말은 이 페이지 안에

예를 들어서 이 페이지 안에 여러가지가 있을 수 있겠죠. 힙 같은 거 우리가 생각해볼 수 있죠. 힙 세그먼트가 이렇게 되어 있는데 내가 여기다가 팔당하고 다 쭉 팔당했는데 후리하고 구멍돌리고 또 후리하고 구멍돌리고 이런 게 발생할 수 있잖아요. 이런 게 더 가중이 되겠죠. 이 페이지가 크면 클수록.

뭐 이거 힙은 조금 이렇게 생각할 수도 있는데 이렇게 생각하면 아마 이해가 더 빠를거에요 내가 이 하나의 페이지가 여러분들이 생각할 때 예를 들어 뭐 16K바이트라고 칠게요 여기 기준으로 그리고 앞에서 얘기했던 하나의 페이지 크기가 아까는 4K바이트였죠 하나의 페이지가 이런 크기라고 했을 때 내가 예를 들어서

4kg짜리를 3kg짜리 뭔가를 할당하고 싶어요. 3kg짜리. 3kg짜리. 여기다 할당하고 싶어요. 이 위에다가 할당할 때는 이만큼 할당이 되고 여기가 이제 남겠죠. 근데 위에는 거의다가 잡아먹고 이만큼이 남겠죠.

이런 얘기를 하는게 인터넷 패브멘테이션이에요. 큰일수록 이 공간을 꽉꽉 치우기가 쉽지가 않다. 그런 얘기를 하고 싶었던 거예요. 오케이. 그렇기 때문에 이런 문제가 발생하고 특히 이런 예제가 여기 나와 있는데요. 우리가 코드도 있고

우선은 그런 문제가 발생한다는 거고 인터넷 표정 페이지 발생한다는 거고 또 다른 문제는 뭐냐면 그 페이지 테이블 안에 안 쓰는 공간이 너무 많다는 얘기를 하고 있는 거예요. 안 쓰는 공간이 많아서 많기 때문에 이 페이지 테이블을 전체를 내가 다 거장을 하고 있는 게 되게 나름기가 크다는 얘기를 하고 싶었던 거고요. 이 예제는 무슨 예제냐면

왼쪽이 Virtual Address Space이고 오른쪽이 Physical Memory일 때 각각이 이거 하나하나가 다 페이지에 드리고 이 메모 한 박스들이 다 페이지에 드리고 오른쪽은 페이지 프레임이 드리겠죠 이게 Corresponding, Mapping이 이렇게 돼 있자라고 할 때 할 때 지금 이 Free 영역이 꽤 많잖아요 근데 우리 페이지 테이블은 이 모든 페이지 넘버에 대한 테이블 구성을 해야만 하죠

그렇기 때문에 우리가 사용하고 있는 공간은 실제로 여기 코드 힙 스택에 대한 요것만 사용하고 있기 때문에 그 페이지 테이블에서 실제 사용하고 있는 친구들 용암 밖에 없다는 겁니다. 나머지는 다 안 쓰는 친구들이 그냥 공간과 잡고 있다는 거예요. 이런 경우가 충분히 있을 수 있겠죠. 그래서 이런 경우일 때 어떻게 해야 되냐. 이런 경우가 문제가 되는 거 아니냐. 이런 얘기를 지금 문제를 제기하고 있는 거고요.

조금만 더 이 문제를 살펴보면 이런 경우는 우리가 어떻게 사용할 수 있냐면 이 멜리드비트를 통해서 우리가 확인할 수 있다. 그런 얘기를 하고 있습니다. 멜리드비트는 1이다 라고 하면 얘가 어떤 데이터가 할당이 돼서 지금 범위를 하고 있다고 생각을 할 수가 있고 1이다. 그리고 0이다 라는 거는 얘를 활용하고 있지 않다라고 생각을 하게 된다라고 여기서 얘기해볼 수 있습니다.

그러면 안쓰는 영역들을 어떻게 잘 내가 효율적으로 관리를 하고 싶겠죠. 그걸 이제 어떻게 하는지 모르겠다는 거예요. 여기서 그 얘기 해볼게요. 사용하지 않는 영역들이 너무 많다. 이것은 어떻게 잘 효과적으로, 그런데 이게 실제 필기필블상에서는 다 잡혀있는 상황이다.

이걸 해결하기 위해서 가장 먼저 해결하는 것은 하이브리드가 없어집니다. 하이브리드가 없어지고요. 이거는 사실 그래서 이거에요. 앞에서 배웠던 세그멘테이션 있잖아요. 여기 보면 각각의 세그먼트들.

코드나 팁이나 이 스텝들을 마찬가지로 앞에 우리가 배웠던 세그멘테이션 어프로치를 이 페이지 케이블에 적용을 해보겠다는 거예요. 페이지 케이블에 적용을 해보겠다는 게 하이브리그 어프로치입니다. 이 예를 보면은 우리 앞에서 봤던 버추얼 어드레스에 가장 상위의 두 개의 리스트의 이거를 앞에서 마치 세븐트를 위한 비트로 우리가 활용을 해보자 라는 거예요.

그래서 우리가 만약에 요 예술 기준으로 세계 페인 어 아 아 네 뭐 이렇게 활용을 한게 따라 놓고 요 우리가 세그먼트 배울 때 베이스 레지스터, 바운스 레지스터, 바운드 레지스터에 대해서 되었잖아요. 그래서 이 베이스 레지스터도 마찬가지로 여기서 필요하다는 얘기를 하고 있고 베이스 레지스터도 각각의 세그먼트마다

필요하고, Bounce register도 해주면 뭐가 좋냐? 뭘 할 수 있게 되는 거냐면, 이 각각의 테이블 기준으로 이 테이블을 보면, 이 테이블을 봤을 때, 각각의 segment가 시작하는 이거를 우리가 Base register로 거장하고 활용을 할 수 있겠다라고 얘기하고 있어요.

이 친구들. 세그먼트에 대한 레이스 레지스터를. 이게 바로 그겁니다. 이렇게 해서 해보겠다는게 바로 이 hybrid-up-watch이구요. 사실 나머지는 똑같아요. 테이블 자체를 세그먼트로 나눠가지고 처리를 하겠다는게 아이디어예고 그걸 위해서 파핏티를 이렇게 하는거고 이렇게 나누게 되면 우리가 사용하지 않을 세그먼트도 있겠죠. 그거는 그냥 말그대로 테이블 자체를 그냥 활용 안하면 되는거니까 테이블을 피지컬 메모리 하다가 안하면 되겠죠. 활용하지 않는 부분들은. 그런식으로 하면 된다라는거고 나머지 활용하는 세그먼트들에 대해서는 Base Bounce 레지스터를 활용해서 Bounce 레지스터를 통해서 데이터가 활용한 테이블 상에서 어느 끝까지, 테이블 상에서 어디가 끝인지를 잘 익히면 그 뒤로는 그거를 사용이 안된다는 것을 알 수 있으니까 앞에서 했던 것처럼 그거를 이런식으로 관리를 해보겠다는 얘기죠.

이거는 마찬가지로 이런 식으로 하면 되겠죠. 이런 식으로 하면은 구현이 가능하다는 거고요. 핵심은 이거예요. 그러니까 여러분들이 헷갈리면 안 되는 게 이 세그먼트 하이브리드 어프로치에서는 앞에서 세그먼테이션 기반의 방법들과 다른 점은 앞에서 세그먼테이션 어프로치는 전체 피지컬 메모리를 세그먼트화해가지고 관리를 하겠다는 거고 이거는 페이지 테이블만 이 세그먼트 난위로 관리를 하겠다는 게 다르고요. 뭐가 다른데 이해되죠?

아 아 랑 같은게 아니에요 그 방법을 가지고 왔지만 각각의 테이블 단위로 테이블에 대해서 요거를 적용을 한거기 때문에 요 코드를 보면은 그 pte 가 페이지의 맹힐을 가져오는 요구였잖아요 요거에 대해 사실은 요거 없었죠 첫 번째 2기 원래 먹었어요 근데 이 첫 번째 줄을 가지고 와서 어떻게 활용을 하냐면 요코드 오면 제 말이 한번 더 합하게 이해가 될 텐데

다시 그리면은 여기서 얘기하는 virtual address가 이렇게 길게 그렸고 앞에 두 개가 있고 이렇게 나눠 됐을 때 이거를 우리가 segmentation number라고 할게요. sm이라고 하는 거고 이거를 우리가 vpn이라고 하고 이걸 오프스텝이라고 했잖아요.

이게 Virtual Address 라고 할 때 원래는 여기 SN이 없었는데 여기 없고 V팬이 쭉 있었죠? 근데 여기 없지금 추가가 된 거고요 추가가 됐고 그런기 때문에 이 세 개 각각의 비트들을 다 읽어야 되겠죠 그래서 읽고 오기 위해서 SN도 마찬가지로 우리가 막 읽고 있는 Virtual Address 로부터 이 세그멘테이션 마스크를 둔 거 앞에서 이 시프트한 거 똑같이 하는 거예요 그래서 이거를 뽑아오는 거고 V팬도 마찬가지로 똑같이 하는 거고

이렇게 까지 하면은 이제 페이지 테이블을 읽어올 수 원래는 그 vpn만큼 이렇게 해서 우리가 읽어왔는데 읽어왔는데 이때 여기가 원래는 그 전체 페이지 테이블의 베이스 레지스터였잖아요. 그 전에는 얘가 그냥 베이스가 아니라 페이지 테이블 베이스 레지스터였는데 이게 각각 세블먼트의 베이스 레지스터로 바뀌어야 되겠죠. 그래서 이게 그렇게 바뀐 것을 여기서 얘기하고 있습니다.

아까랑 큰 차이는 없는데 각각의 세글 버튼들마다 베이스 레지스터로 바꿔가지고 이것들을 좀 더 효과적으로 가게 되고겠다. 그리고 바우스 레지스터를 실패하는 것도 분명 있어야 되겠죠. 그런 얘기를 하고 있는 거예요. 별로 어렵지 않습니다. 질문 있어요? 네, 괜찮아요. 네.

그래서 이렇게 한다고 해도 앞에서 똑같은 문제가 페이비트 해소로 해서 똑같이 발생을 하겠죠. 마찬가지로 발생을 하겠죠. 앞에서 이 얘기를 할 때 리스터널 프라그멘테이션이 발생을 한다고 했잖아요. 특히 히트셀범벅스 얘기하면서 이 얘기를 말씀드렸죠. 마찬가지로 여기도 리스터널 프라그멘테이션이 똑같이 발생을 할 겁니다. 앞에서 똑같은 이유로. 그래서 얘는 본질적인 행위책이 아니다라고 제가 하고 있는 거예요.

여러가지 문제가 있습니다. 앞에 잠깐 갔다 볼까요? 세그멘테이션 날 때, 익서를 클럽에 대해서는 기억이 안나실까봐. 여기서, 우리가 봤었고, 여기서 쭉 배우다가, 익서를 클럽에 대해서는 이런거. 이게 익서를 클럽에 대해서 이라고 제가 말씀드렸잖아요.

마찬가지로 여기도 똑같이 발생을 하겠죠. 각각의 세브먼트가 있고 난유스가 있을 때 마찬가지로 아까 얘기했던 게 있으면 프레그먼트에 똑같이 발생을 하는 경우 페이지 테이블에 해당하는 지역에 대해서 그렇기 때문에 이게 본질적인 규칙이 아니다라고 요 때 말씀드렸어요. 안 날짚아가 갔다 온 거예요. 이것을 이거 해가려면 섹션을 해야 되는데 내 코스가 가진다. 이 얘기까지 들어가면 돼서

그래서 돌아와서 그래서 이 본질적인 행정이 안다 그러면 이거 어떻게 해결해 보고 싶다 그래서 이제 이제 또 그래서 나온게 이건 진짜 지금도 활용이 되는걸로 전할 수 있는데 정확하지 않은데 하여 얼마 안 됐어요 그래서 멀티 내로 이거를 3 케이블

하얀 스컬하게 만들어보자 라고 생각이 나오는 겁니다. 사실 이런 컨셉은 지금도 엄청나게 많이 있어요. 여러분들 오맛에서 트리 를 이용한 데이터 스튥처를 많이 쓰고 있잖아요. 여기도 트리 를 활용해보겠다는 것이고 이 트리가 되게

효과적인 친구예요. 이 트리라는 친구가. 트리라는 친구가 왜 효과적이냐면은 우리 랜글랜 트레이서도 배웠지만 이 트리를 통해 가지고 되게 많은 거라고 할 수 있습니다. 그러니까 내가 이 트리라는 걸 본질적으로 왜 얘가 좋은 거냐면요. 얘를 왜 쓰냐면 얘를 개친구화 할 수 있잖아요. 개친구화. 이게 되게 파워풀한 개념인데

노드가 있고 이렇게 이렇게 이렇게 이렇게 우리가 이거를 확장을 해 나가잖아요. 얘를 왜 많이 쓰냐면은 이게 이런 식으로 연결이 되어있죠. 프리가. 이렇게 연결이 되어있죠. 이거는 그냥 어두예요. 오늘 이걸 말씀드리기 위한 얘가 왜 좋은지를 말씀드리고 싶어서 설명을 하는 거고요.

이런 식으로 계층화가 이렇게, 얘는 뭐, 얘는 뭐더라구요. 얘를, 뭐 레벨 원 투, 뭐 쓰리 이렇게 구성이 되어있잖아요. 이 밑으로 갈수록, 밑으로 갈수록 뭔가 더 디테일한 정보들. 더 개수가, 노드의 개수가 많아지죠. 그러니까 내가 어떤 공간을 표현하던지 어떤, 어떤 걸 표현하고 싶어요. 어떤 것, 어떤 것이든 표현하고 싶은데, 이 밑으로 내려갈수록 디테일한 정보들을 표현을 하고 이 디테일한 정보들을, 요 각각의 이, 테라우스 노드들, 요 친구들이 얘가 가지고 있는 그, 쉐어드 노드들에 대한, 뭐가 그런, 그런 압축된 정보. 얘를 대표할 수 있는 뭔가 압축된 형태의 정보를 여기다가 저장해 나가는, 그런 것들을 요구현을 할 수가 있다라는 게 이 트리의, 이 그 단점이고, 여기도 그렇게 똑같이 활용하는. 무슨 말이냐면은, 그러니까 요런 개념 때문에 트리를 많이 활용하는 거고요.

그래서 얘를 실제로 지금 어떻게 하는 거냐면 이렇게 하는 겁니다. 이렇게. 되게 복잡해 보이는데 이 그림을 간단하게 보여드릴게요. 간단하게. 간단하게 다시 그리면 이게 페이지 테이블이라고 할게요. 페이지 테이블이라고 할게요.

페이태리 태블리입니다. 요것들이 요것들어서 요기는 내가 쓰고 있고요. 요기도 내가 쓰고 있어요. 나머지는 기어있어요. 또 이렇게 있죠. 그러면은 얘를 전체를 표현을 하면은 이 빈 공간에 대해서 내가 이걸 뭔가 표현을 할 수가 없고 이걸 표현하려면은 이 각자 모든 엘리먼트들, 엔트리트들을 다 내가 알고 있어야 되잖아요.

이렇게 하지 않고 얘를 대표할 수 있는 뭔가의 트리 구조로 만들면 어떻게 할 수 있다면 얘를 만약에 두 개로 나눌게요. 아니 세 개로 나누세요. 이렇게 하나, 둘, 아 이건 트리가 아니구나. 네 개로 나눌게요.

4개 이렇게 4개를 이렇게 나누고 나눠보겠습니다. 1,2,3,4 그러면 가장 위에 있는 트리에서 내가 이 친구를 이 구조를 이게 이렇게 되는거죠. 원래 10개짜리라고 쓸게요. 이게 10개가 아니라 8. 각각이

이 안에가 예를 들면 n개 라고 칠게요. 이게 n개의 엔트리기로 이루어져 있다고 칠시면 이 n개가, 이게 n개예요. n개가 곱하기 4개만큼 있는 거죠. 이렇게. 이렇게 4개. 원래는 이 전체의 네트리 크기는 n 곱하기 4이잖아요. 근데 테이크에 우리 이 전체 크기를 다 저장을 하고 있어야 되는데 이 부분을 내가 압축을 해가지고 n개, 이 n개에 대한 이 정보를 이 위에 있는 이 모드 하나를 써서 얘를 대표하겠다는 거죠. 이게 컨셉이에요 사실. 얘가 문제입니다.

이렇게 만들어진다는 거예요. 이렇게 만들면은 내가 뭐라고 할 수 있자면은 이 친구, 1번이라는 친구는 뭔가가 있어요. 안에 데이터가 있다. 그럼 얘는 valid다. valid다. 라고 얘를 이 노드를 그냥 정해버리고. valid다. 그러면 얘는 있는 친구다. 그러면 얘는 보니까 없어요. 두 번째는 없어요. 그러면 얘는 valid가 1이고 얘는 valid가 0이야. 얘는 없어. 안에가 비어있다. 라고 하면은 얘는 그냥 이 이 리프 노드는 그냥 없어. 내가 얘를 몰라도 되겠죠. 그렇게 되면은.

얘는 내가 저장할 필요가 없어지겠죠. 얘는 어차피 이 안에 아무 어떤 정보도 포함하고 있지 않으니까 내가 이 차이드로드를 내가 따로 기억하고 있을 필요가 없이 내가 N개의 차이드로드를 다 그냥 어차피 없어있다. 내가 그냥 판단을 내려버릴 수가 있겠죠. 그렇게 하는 게 바로 이 멀티매들 페이지 케이블이라는 거예요.

그 뒤에 분위기가 어렵게 그려져 있어서 제가 추상적으로 다시 설명을 하는 겁니다. 이 예제에서. 이게 뭔 말이 이해 돼요? 이 예제를, 이 생각을 가지고 뒤를 가면 이제 이게 보일 거예요. 똑같이 그려놓은데 사실은. 똑같이 그려놓은 거고요. 지금 전체 이 네 개.

이 전체가 원래 하나의 페이지 테이블이에요. 이 전체가 페이지 테이블입니다. 그리고 여기 오타인데 원래가 알고 있는 폰에서 더해놓았던 페이지 테이블 베이스 레지스터가 여기를 시작적으로 가지고 있어야 되겠죠. 거기 더하기 우리가 사이즈 오브 엔트리 그 복해가지고 그 vpn 해가지고 했잖아요.

그렇기 때문에 이렇게 구성이 되어 있던 것을 4개의 각각의 뭔가를 나누거구요. 그거를 다시 여기서 페이지 프레임 이라고 얘기를 하고 있고 그래서 이걸 4개씩 나누는 겁니다. 이렇게 4개로 나누는거에요. 앞과는 똑같이. 이 4개로 나눈 다음에 이 4개를 대표하는 그 하나의 노드. 앞에서 봤을 때 이 파란색으로 제가 말씀드렸듯이 이 하나의 노드들이 여기서 왼쪽에 있는 이게 이렇게 지금 나눠지는 부분입니다.

요 하나가 그렇게 되는 거예요. 요게. 요거는 안타입. 이렇게 할 수 있겠죠. 그렇게 되면은 얘가 이 친구고 얘가 이 친구다 라고 얘가 이 친구고 얘가 이 친구다 라고 내가 알고 있으니까 요거를 봤을 때는 이 친구 첫 번째 친구를 봤을 때는 뭔가 있다. 멜리디가 있죠. 멜리디가 1이다 라는 걸 보고 얘가 1이니까 얘는 어딘가에 저장을 다시 요 숫자, 요 네틱이 된 정보를 저장을 하고 있어야 되겠죠.

그 정보가 여기 저장되어 있다. 오른쪽에 그거를 실제 피지컬 메모 이상에 저장해놓고 여기 아래에 있는 페이지 프레임 넘버가 또 있어요. 페이지 프레임 넘버가 있어서 이걸 통해서 여기를 접근을 하겠다는 얘기가 있어요. 이해를요. 그래서 여기 왜 2021이냐? 여러분들 궁금하실 수 있잖아요. 이 시작 주소가 2021이라고 생각하면 돼요. 여튼 이상할 수 있는데 2021이고 이 시작 주소가 2022라고 생각하시면 돼요.

그냥 요 이제 찾는 부분은 이상해도 그냥 넘어가지세요. 왜 일식된가? 이렇게 생각할 수 있지만 그래서 이렇게 구성되어 있는 겁니다. 그러면 내가 2021이라고 하면은 여기를 내가 덮어낼 수 있겠죠. 페이지 프레임 너버를 통해가지고 덮어낼 수 있게 해가지고 뭐 이렇게 할 수 있는 거고 요 밑에를 봤을 때는

비어있으니까 안에 있는 모든 엔트로 정보들을 내가 따로 저장할 필요가 없겠죠. 그냥 비어있다고 내가 이 메네디리트 보고 그냥 비어있는 친구자라고 판단 내리면 되잖아요. 얘는 내가 따로 저장할 필요가 없고 마찬가지로 마지막 친구에 대해서도 메네디리트가 1이니까 얘도 여기 저장 어딘가에 저장이 되어있다. 이렇게 하면은 결제 페인피수가

페이지는 페이지 후에 이 업계가 빌바를 줘 하나가 하나가 되겠죠 2개가 할 수 있는데 예를 들면 해야 되죠 그 친구도 어디서 우리 피지컬 메모리 저장해야지 예를 수도 있겠죠 그래서 하나가 세이브가 되죠 물론 이 페이지 브레이크리와 여기 예제에서는 그 각각의 페이지 프레이들이 크기가 같기 때문에 그렇게 얘기할 수 있습니다 그래서 이 전체를 이 전체를 저장하고 있는 이 친구 있잖아요 이 친구를 우리가 그냥 페이지 테이블이라고 부르면 안되겠죠 페이지 테이블 이미 이름을 썼으니까 그래서 페이지 디렉터리라고 여기서 부릅니다

그렇게 되면 아까 얘기했던 페이지 테이블 베이스 레지스터도 마찬가지로 바뀌어야 되겠죠. 그래서 이것도 못한데 페이지 테이블 베이스 레지스터도 이 페이지 드래토리를 가리게끔 바뀌게 됩니다. 멀티레벨 페이지 테이블에서. 이거는 투레벨 페이지 테이블이에요. 투레벨, 그러니까 레벨이 두 개죠. 레벨 첫 번째 레벨과 두 번째 레벨.

그래서 그 얘기를 그대로 하고 있습니다. 그래서 그 얘기도 같이 하고 있는 거고요. 그래서 페이지 그래프리 안에 있는 각각의 엔트리들을 페이지 그래프리 엔트리라고 이름을 따로 골라야 되겠죠.

페이지 테이블 엔투리랑 헷갈리면 안되니까. 그래서 여기 따로 고르는거고 이렇게 하면 장점이 음..뭐야? 이런것들. 그..뭔가 내가 그런..뭔가를 다시.. 앞에서 같이 이스넬 프레그먼테이션 이슈가 많이 해결이 되겠죠. 이스넬 프레그먼테이션은 중간중간에 구멍이 뚫려 있을 때 이렇게 하면은 그 공간이 커지고 작아지고 했을 때 그런것들을 이렇게.. 그..디 베토리를 관리를 하면은 그런것들을 내가 쉽게 관리를 할 수 있으니까 이런 부분에는 장점이 있는데 단점이라고 하면은 복잡하죠. 시간이 좀 더 걸리겠죠. 이 디벡토리도 관리를 해야 되니까 또 복잡하고 이런 장단점이 있다라고 얘기를 하는거고

그래서 실제로 예제를 보면은 이렇게 구성이 됐다 라고 얘기를 하고 있고요. 이건 그냥 예제고요. 저는 예제가 아니라 앞에서 갔던 거 똑같은 얘기를 하고 있는 거예요. 그러면은 이게 페이지 디렉토리가 되겠죠. 페이지 디렉토리를 그냥 대략적으로 그려놓은 거고 실제로 이거는 뭐

실제로는 여러 개의 엔트리들로 이루어져 있는데 첫 번째 페이지와 두 번째 페이지에 코드 세그먼트가 들어가 있고 그 얘기를 하고 싶었던 거예요. 아까 봤던 그 예제를 첫 번째 페이지와 두 번째는 코드 세그먼트 네 번째와 다섯 번째는 C. 그리고 페이지에는 스택이 들어가 있기 때문에 이게 요거에 대한 실제 테이블을 유지를 하면 되고 나머지 친구들은 이 테이블 유지를 할 필요가 없다. 그냥 이 얘기를 하고 싶었던 거거든요. 또 얘기하는 게 아니라

그러면 실제로 어떻게 내가 구현을 하냐를 살펴볼까요. 앞이랑 비슷하겠죠. 비슷할거에요. 원래 vpn 이렇게 구성되어 있고, 옹색이 이렇게 구성되어 있을 때, 이게 지금 몇 bt야? 그러면은

얘는 6개 밑이죠. 갑자기 넘어오면 헷갈릴 수 있으니까 얘는 virtual address구요. 지금 뭘 하려고 하냐면 virtual address가 이렇게 주어졌을 때 내가 각각의 그...

지금 뭘 하고 있는 거냐면은 그 거예요. 페이지의 드래퍼리를 어떻게 구성을 하는지를 살펴보겠다는 거고요. 이게 VA가 벌써 이렇게 구성이 되어 있는데 이게 지금 8bit고, 그러면 얘는 전체가 14bit에서

14비트에서 6.75바이트짜리 어드렷 스페이스가 있을 때 아 여기 나와있네요. 페이지 사이즈 사이즈 어디있냐 찾아놨는데 여기 나와있네요. 그러니까 페이지 사이즈란 여기서 말하는 페이지 사이즈는 페이지 디렉토리를 만들기 위한 페이지 사이즈를 얘기하고 있는거에요. 내가 페이지 사이즈를 64바이트로 만들고자 했을 때 페이지 테이블이 어떻게 구성이 되느냐는 설명을 보겠다는 거고요. 그렇게 됐을 때 그러면 전체 이 vtn은 2의 87개만큼의 페이지 테이블이 엔트리가 있으니까 2,56개의 엔트리가 있겠죠. 실제 원래 페이지 테이블이 있죠.

무슨 말이냐? 우리가 원래 가지고 있는 페이지 테이블 있잖아요. 페이지 테이블. 이 친구가 이 하나들이 엔트리 라고 제가 말씀을 드렸을 때, 이 하나가 엔트리다 라고 말씀을 드렸을 때 이 엔트리의 개수가 이 개가 VPN 개수만큼 있었다 라고 말씀을 드렸으니까 이 VPN의 개수는 2의 8승이잖아요. 그렇기 때문에 2, 5, 6개 만큼의 페이지 테이블 엔트리가 있다라고 우리가 여기서 지금 확인할 겁니다. 첫 번째.

이 엑트리가 있을 때 페이지 테이블의 사이즈도 한번 구해보면 이렇게 구해진다는 거예요. 이거 vpn 곱하기 사이즈가 엑트리. 이거 4바이트. 곱하면 전체 테이블 크기가 나오겠죠. 1K바이트. 1K바이트 나오죠. 1K바이트를 그러면 이 페이지 그 다음에 뭘 하고 싶은 거냐면

이 친구를 이렇게 페이지와 시키고 싶은 거고요. 페이지 프레임을 이렇게 만지고 싶은 거고 쭉 이렇게. 이거 하나의 크기를 내가 64바이트로 하고 싶은 거예요. 그러면은 이거는 이거는 전체 이 테이블의 크기인

1K 바이트, 1K 마이트, 나누기 64 바이트 하면 나오겠죠. 이 개수가 나오겠죠. 그거 하면 16개 나오다 라는 얘기를 하고 싶었던 것들이에요. 이렇게 구할 수 있는 거예요. 이 예색 기준으로 구할 수 있겠죠. 그러면 그래서 이렇게 됐다 라는 얘기를 하고 싶었던 겁니다. 이렇게 만들어졌다. 각각이 이렇게 되면은 16개의 페이지가 나오고 64, 사이즈가 64니까 페이지 페이블 엘트비가 4 바이트니까

얘는 4로 나누면 16이 또 나오죠. 그래서 엔트리의 개수, 각 하나 페이지 안에 있는 엔트리 개수도 16개다. 16개. 이게 나오는 거예요. 그래서 여기 페이지 수도 16개. 이 기준으로 이렇게 나오는 건데요. 이 숫자들이.

이거 사실 아까 했던 거를 똑같이 하는 거라서 쉽죠? 네, 별로 어렵지 않죠. 그 얘기를 계속하고 있어요. 그렇게 했으니까 지금 요번에 봤을 때 우리가 16개니까 이 페이지 페이로 엔트리에 대한 페이지 디렉토리에 대한 그 엔트리의 개수도 또 내가 알 수 있죠.

그게 총 16개를 내가 표현할 수 있어야 되잖아요. 16개는 2에 4승이죠. 그래서 또 비트가 4개가 추가가 돼야 된다는 얘기를 결과적으로 하고 싶었던 거예요. 4개가 추가가 돼야 된다. 추가가 아니라 V팬이 그만큼 반만큼 잘라내던 거죠. 결과적으로 여기까지 온 겁니다.

질문 있어요? 네. 하이브리드 업로치는 개선된 게 없다고 하셨는데 그러면 뭘 어떻게 개선하려고 시도하고 아! 개선된 게 없다는 게 그 아까 얘기했던 페이지 테이블의 크기를 줄이는 건 개선이 됐지만

똑같은 익스런 프레그맨테이션이 똑같은 문제, 앞에서 봤던 그 문제가 여전히 여기서도 있다는 얘기예요. 페이지 테이블의 개수가 줄어드는 이유가 그 VPN의 개수가 뭐예요? 어.. 그게 줄고 우리가 세븐니테이션 봤을 때 그 각각의 세븐니테이션의 크기를 베이스 마운스 레지스터를 통해 가지고 우리가 확인을 했잖아요.

앞에서, 그렇죠? 그걸 여기서 똑같이 적용을 하면은 지금 여기서 하고 싶었던 건 뭐냐면은 앞에서 세브멘테이션 어프로치에서도 CD랑 코드 사이에 Free Chunk들이 크게 있는데 그것만큼 Physical Memory 그대로 얘를 잡고 있으면은 똑같은 문제가 발생, Free Chunk들이 Physical Memory에도 그대로 할당이 되니까 뭔가 이제 낭비되잖아요. 여기도 테이블에 대한 사용하지 않는 구역들이 테이블로 잡혀있는 게 아까웠던 거고 요거를 해결하기 위해서, 요 문제를 해결하기 위해서 여기가 똑같이 세브멘테이션 기반의 아이디어를 가지고 와가지고 요 공간 자체도 세그먼트 단위로 나가서 관리를 해보자 그때 마찬가지로 베이스 레지스터를 각각 세그먼트들의 시작 위치와 이렇게 되면은 끝나면 이 바운스도 여기가 되겠죠. 바운스가 여기가 되죠. 바운드. 여기도 바운드.

여기 바운드. 각각 생어먼트들에 대한 바운드도 내가 정해줄 수가 있잖아요. 이거를 활용하면 이 전체 테이블을 내가 다 밑에를 알 필요 없이 여기를 몰라도 바운드 레지스터를 통해서 내가 끝나는 위치를 확인하겠다는 거예요.

그렇게 하는 공간을 내가 테이블을 피지컬 메모리 다 잡아볼 필요가 없잖아요. 근데 이렇게 요번 해결했는데 이 세그멘테이션 어프로치의 한계인 그때도 얘기했다. 한계인 이 스타러 프로그롱 텐션이 여기 똑같이 발생하나? 다른 문제지만 문제 알겠죠? 오케이

또 다른 질문 있어요? 저 14페이지는.. 잠깐만요. 네. 저 그림이 보여주는게.. 저.. 16KB 스페이스에 베이지 테이플.. 베이지 테이플 16개를 꽉꽉 채우는 그림이죠. 꽉 채웠다는건 사실 뭔지 다 이해를 못하겠는데 이 예제를 그림으로 그대 불러주는데 이렇게 나온다는 거예요.

요거 맞죠 요거를 근데 페이지 0부터 10까지 그려져 있는데 각 페이지 안에 페이지 프레임 넘버 이게 네 페이지 안에 페이지 테이블이 그려져 있는 게 아니라 페이지를 나누고 있는 여기서 얘기하는 페이지 프레임 넘버는 실제 피지컬 메모리 주소예요

실제는 이 집가 내버린 이 이게 지금 이 탭으로 나누어 자라요 아 예 아 예 이거는 아니요 이거는 ppp 피지컬 내고 있는 시제 페이지 테이블 그래서 지금 얘기하고 있는 건 페이지 테이블을 나눠 보겠다 페이지 테이블 너무 크니까 피지컬 메모리 페이지 테이블을 다 저장을 해야 되잖아요 그걸 안 하고 싶은 거예요

근데 여기서 얘기하는 이 페이지 프레임 넘버 이거는 실제 얘도 페이지 테이블의 배축 자체가 버전 어데스를 피지컬 메모리로 트랜스레이션 해주는 거잖아요. 이 VPM은 원래 이거 자체가 페이지 테이블이었으니까 나누기 전에 나누기 전을 보면 얘는 VPM이 0번일 때 페이지 프레임 넘버가 10번으로 트랜스레이션 된다는 원래 정보가 들어있었겠죠. 그 정보를 표현한 거예요. 얘는 VPM이 1번일 때 페이지 프레임 넘버 2, 3번으로 트랜스레이션 된다. 원래 그 정보가 들어있었는데 기어 있다는 거는 그 NLID 비트가 0이다. 활용하지 않는 거라는 걸 표현하고 싶었던 그림이고요.

이렇게 됐어요. 원래 이 역할을 쓰인거 친구를 이렇게 다시 페이지로 나눠가지고 똑같이 써보겠다는 얘기하고 싶었던거에요. 오지 않겠죠? 네. 오케이. 네. 그 트리 형태로 하는 이유가 네. 히스테이글의 사이즈를 추리기 위해서 맞아요. 그게 목표인거에요. 네. 그런데 그

프레임 테이블이라서 그게 전부 다 만약에 벨레드가 다 1인 상태면 결국에는 그냥 리니어하게 관리하는 거랑은 차이가 맞아요 크기는 안 되겠죠 그럼 동일한 부분은 동적으로 그냥 관리 되는 거에요 어.. 얘는 그러니까

아까 얘기했듯이 다 차 있으면 오히려 택이 디렉토리 하나 더 추가되는 형태가 되겠죠. 근데 그 상황이 많이 발생하지 않을 거기 때문에 보통은 우리가 그걸 다 쓰지 않기 때문에 많은 프로그램들이 있습니다. 그렇기 때문에 그런 경우에서 효과적으로 요구가 나오고요. 그러니까 등적으로 관리가 되는 것도 맞고

아 맞습니다. 네. 네. 그러면은 그 트리의 레벨이 증가할수록 페이지 제풀이 수도 증가할까요? 아 좋은 질문이요. 그거 지금 할 거예요. 네. 그래서 멀티 레벨이 있습니다. 지금 레벨 2개짜리만 얘기하고 있잖아요.

그래서 지금 여기서 이렇게 관리가 되겠죠. 결과적으로. 지금 이렇게 나눈 다음에 이거를 각각을 관리하기 위해서 페이지 디레이처에 인텍스하고 이 하나로 빼서 지금 이렇게 빼서 얘기했던 게 아까랑 똑같은 거죠. 지금. 결국 여기까지 온 거예요. 그래서 얘기했던 게. 아까 이렇게 엔트리 들로 페이지들로 테이블을 나누고 그게 밸리드가 한지 아닌지를 이 디레토리를 통해서 내가 확인하겠다라고 해서 투자별로 나눈 거예요.

우리 첫번째 여기까지 따라왔죠. 그 다음에 얘를 아 그래서 이것도 우리가 이렇게 하면 알 수 있다는 것을 아직 안해도 되죠. 이거 똑같은거에요 사실 이거 뭐 별거 아니고 페이지 테이블 엔트리의 워드레스를 구하기 위해서는

어 이 페이지 렉토리 엔트리 안에 있는 페이지 프레임 넘버 가 그 요요요 요 친구 요 친구가 여기가 되겠죠 여기가 되겠죠 그 다음에 그 페이지 이 테이블 인덱스에 해당하는 요 친구

이 친구들, 여기서. 이 각각을 이렇게 구해서 이렇게 넣어주고 이렇게 하면 이 페이지 테이블의 address가 나온다. 여기서 말하는 그 int, 페이지 테이블의 entry address는 여기서 얘기하는 각각 이 친구들, 실제 우리가 원래 알고 싶었던 페이지 테이블의 entry를 알기 위해서는 이 directory에 있는 이 entry들을 통해서 이거를 접근을 하고, 이 화살표로 접근하고 그거로부터 얘를 읽어야 되잖아요. 그 과정을 우리가 논리식으로 다시 재표현하면 이렇게 표현할 수 있겠죠.

아 그 얘기하고 있는거에요. 여기서 왼쪽에다가는 이게 그 화살표에 해당한다라고 설명돼요. 그 페이지 프레임 넘버에를 지금 읽어보는거니까. 여기까지 해서 우리가 지금 다 배운거구요. 그래서 결과적으로 이 마지막 예제, 이 예제 기준으로 마지막 예제를 보면은 2ml 기준으로

싱글 레벨 짜리 16페이지를 이렇게 지금 활용하고 있는 구역에 지금 이것밖에 없을 때 나머지는 다 풀이에요. 이것 기준으로 3개의 페이지를 활용을 해서 이것을 표현할 수 있게 됐다는 것입니다. 16이 3으로 줄었다는 얘기를 하고 싶은 겁니다.

이걸 표현하기 위해서는 지금 요거에 대한 어 네 요거에 대한 그러니까 요거 페이지가 지금 요게 지금 하나의 페이지였잖아요. 앞에 예시를 보면은 요 예제 기준으로 요거 하나 지금 얘가 아까 코드고 얘가 힐였잖아요. 힐

얘를 하나의 페이지로 표현을 했으니까 이 두 개의 세그먼트를 하나로 표현이 됐겠죠. 그래서 그거를 여기서 얘기를 해가지고 지금 여기가 코드고 여기가 힙에 대한 게 이 하나의 페이지로 표현이 됐기 때문에 여기가 하나인 거고요. 그리고 이거에 대한 페이지가 필요한 거죠. 그게 여기 두 개인 거고. 이 전체를 표현하기 위한 페이지 디렉토리 세 개. 그래서 세 개인 겁니다.

왜 코드랑 티비가 왜 이렇게 해서 생기가 아니었라고 물어볼 수 있는데 이게 첫 번째 테이프에서 다 표현이 되기 때문에 하나로 표현이 되었어요. 알겠죠? 이렇게 해서 다 얘기했고 그러면 아까 질문이 나왔는데 그러면 두 개만 되는 거냐? 그래서 두 개보다 더 많이 도와줬어요.

당연히 할 수 있겠죠. 그래서 이것까지 할 수 있을까? 사실 이거는 여러분 빨리 끝내줄까요? 시험 기간인데 꼭 채소서 수업하고 싶지 않아요. 사실 저도 여러분이 궁금한 시간을 조금씩 주기 위해서 사실 똑같은 얘기하고 있어요. 똑같은 얘기하고 있고 이거는 그냥 간단하게 넘어갈게요. 사실 이거는 좀 너무 복잡해지니까 똑같은 얘기를 한 번 더 합니다. 한 번 더 하려면 그래서 월인토라고 하면 세 개로 얘기하고 싶은 거예요. 세 개로 하고 싶은 거 보고 결과를 먼저 보고 오면

우리가 이렇게 해서 두 개로 나눴잖아요. 두 개로 나누는데 이 공간이 매우 크다라고 하면은 이 페이지 디렉토리도 결국 얘도 커지는 거 아니라고 얘기하고 싶어요. 얘도 큰 거 아니야. 그러면 얘도 크면은 얘도 한 번 더 나누면 되겠죠.

예를 들어 한번 더 나눠 가지고 이렇게 요거 하나 더 얻고 계층을 하나 더 올린 거예요 그 또 이 공간을 다시 표현하기 위해서 하나를 더 가지고 요렇게 표현하겠다는 거예요 별로 이거는 똑같은 얘기하고 더 하는 겁니다 아까 봤던 아까는 그 이 전체 이 크기를 이 외모

전체 실제 페이지 테이블을 하나의 페이지 디렉토리로 표현을 했었잖아요. 이렇게 표현을 했었는데 이 페이지 디렉토리도 이 페이지 테이블이 매우 크다고 하면 얘도 커지니까 얘를 한 번 더 나눠서 다른 페이지 디렉토리 여기 더 상위 레벨에 있는 얘를 다시 이렇게 표현을 해보자. 이렇게 할 수 있겠죠. 그래서 이걸 똑같이 하는 거예요. 그냥 똑같이 또 한 번입니다.

그래서 이걸 하기 위해서 아까 했던 이 예제를 못 얘기하고 있는 거냐면 결과적으로 이렇게 빗줄 수가 지금 많아졌다는 것은 vpn이 커졌죠. vpn이 커졌다는 것은 페이지 테이블의 크기가 매우 커졌다는 얘기를 하고 있는 거죠. 그 페이지 테이블의 크기가 커졌을 때 페이지 사이즈를 이렇게 잡으면 이렇게 512로 아까 보다 크게 잡았죠. 아까 이렇게 다 512로 늘어났잖아요. 이렇게 늘어나도 이 페이지 디렉토리에 mt가 결과적으로 이렇게 해보면

이게 시상에 어떤 들어가는 안 거야 제가 해보면 이만큼 예시작에 만큼 기울기가 필요하다 개선이 이렇게 나와요 이렇게 나온다는 거고 어 이렇게 나오기 때문에 요거를 요 그림에서 그래서 결과적으로 요구를 요렇게 이 디렉토리에 이 시각의 오픈에 엔트리가 또 페이지에 엔트리가 필요하고 이러기 때문에 얘도 요 한층을 더 보고 얘를 더 줄여보자

안으로 그렇게 해서 결과적으로 이렇게 표현할 수 있다. 그 다음에 얘기가 좋은 거예요. 질문이 있어요. 뭔 말인지 알겠죠? 앞에 거 이해되면 이거 똑같은 얘기라서 뭔 말인지 알 거예요. 그래서 빨리 넘어가는 겁니다. 얘가 주기가 나타나는 얘기가 아니라 그래서 얘를 지금 코드로 표현을 하면은 이거를 잠깐만요.

아 이거 해야 돼 이거는 이거 알 수 없어요 이거 감사합니다 여기까지 다했어요 이렇게 했는데 그래서 뭔 얘기를 하고 싶은 거냐면 여러분들 이 그림을 볼게요 그 코드를 자세히 들여다보기보다 이 그림을 딱 봤어요 얘는 지금 어디에 제작되겠죠 이 친구들은?

어디 저장되어있죠? 페이지 테이블 올라가고 어디 저장되어있죠? 피지컬 메모리 저장되어있죠? 그러면은 우리 원래 페이지 테이블 접근을 하지 피지컬 메모리 접근을 했을 때 앞에서 예제를 적었을 때 내가 어떤 포드 세그먼트 하나 접근하고 싶어요. 피지컬 메모리 포드 세그먼트 어떤 데이터를 그러면은 페이지 테이블을 갖다가 그거 페이지 프레임 너버에 읽어와서 그걸로 접근해서 두 번 extra 레퍼런스가 발생한다고 말씀드렸죠?

이거를 보면 내가 여기 겪고자고 싶어요. 여기. 여기. 그러면 먼저 여기 가야죠. 얘 어딨죠? 피지컬 메모리 있죠? 얘를 통해서 여기를 알아와야겠죠. 여기 위치. 그 다음에 여기 한 번 더 접근하죠. 그 다음에 얘가 포함되어 있는 여기를 내가 알아와야겠죠.

그 다음에 얘를 활용해서 다시 여기 놓아야 되겠죠. 세 번으로 눌렀죠. 그 얘기를 이 코드에서 하고 싶었던 거예요. 앞에서 봤던 그 짓을 그래서 이 TLD를 봤을 때 히트가 나면은 이 히트가 나면은 피지컬 메모리 그냥 바로 읽으면 돼요. 피지컬 메모리를 그냥 내가 읽고 싶은 글씨도 바로 읽어놓은 거예요.

근데 이거는 문제가 없어요. 한 번만 딱 읽으면 돼요. tld에 히트가 나와요. tld 미스가 떴다. 그러면 이때부터 골창 빠지는 문제. tld 미스가 떴어요. 미스에요. 미스. 미스가 떴습니다. 그러면 페이지 디렉토리 엔트리 읽어버리기 시작해야 되죠. 앞에서 부서. 첫 번째 페이지 디렉토리 가서 이거 하나 읽어와요. 페이지.

요거 읽어 옵니다. 읽어 온 다음에 한 번 더 가야 되죠. 한 번 더 그 다음 예를 가서 한 번 더 읽어야 되잖아요. 그거를 여기서 한 번 더 해야 돼요. 두 번 했죠. 그래서 결국에 마지막으로 페이지 테이블 엔트리 구한 다음에 얘를 CLB에 넣어줄 수 있겠죠. 이렇게 넣어주고 이 retry instruction이라는 걸 그때 제가 따로 말씀을 안 드렸는데 다시 얘를 한 번 더 실행하겠다는 거예요. 야구 돌아와

내가 여기 키에 넣어놨으니까 내가 지금 가보자는 그 엘트리바이 키에 들어가 있죠. 그 다음에 앞으로 돌아가면은 여기도 다시 하면 되죠. 여기부터 다시 하면 되죠. 그러면은 여기 이거 보면은 얘가 키에 들어가 있죠. 그래서 석세스가 필요가 되겠죠. 그래서 다시 일로 들어오는 겁니다. 이렇게 해서 총 3번 피지컬 메모리를 접근을 해야 된다 라는 얘기를

하고 싶었던 거예요. 네 질문. 그러면 CPU가 갖고 있는 것들은? 요거 접근하는 것들이요? 네. 접근하는 것들은? 접근하는 것들. 접근하는 것들. 잠시만요. 실제와 어떻게 설명할지. 저도 이거 제 역분야가 아니라서 한번 얘기하면 자꾸 까먹어요. 그래서 지금 리만을 좀 해야 되는데 - 네.

음... 접근하는 게 CPU가 메모리 매인거 뒤에서 할 것 같아요 이거를 CPU가 하진 않을 것 같아요 이게 저 앞에 모르겠어요 이게 한번 내가 봤던 것 같은데 기억이 잘 안 나요

M1가 맞아요? 아 맞네요. 제가 기억이 잘하고 있었네요. 네 좋습니다. 오케이. 하여가 이걸 하던 어떤 분 간에 이걸 접근할 수 있다는 것 자체가 시간이 걸린다는 거니까 그 얘기를 하고 싶었던 거예요. 어쨌든 한 번 하고 두 번 하고 세 번 해야 되니까 이런 장단점이 있다 라는 얘기를 하는 거고

마지막이요. 이거는 그냥 가볍게 들으셔도 돼요. 마지막 가볍게 들으셔도 되고, 빨간해지고 싶었는데 이렇게 들으셨네. 그래서 지금 이거는 우리가 페이테이블을 Virtual Frame Number부터 Page Frame을 찾아갔잖아요. 반대로 할 수 있다는 얘기를 하고 있었던 거예요. 우리가 Page Frame Number를 통해가지고

그걸 통해서 거기를 가리키고 있는 virtual frame numbers이 뭐가 있는지를 반대로 나눌 수 있겠죠. 그게 inverted pay table이고요. 원래 우리가 했던 게 이 vpn을 통해서 각각의 엔트리를

접근을 했잖아요. 이걸 접근을 했잖아요. 이걸 반대로 하고 싶잖아요. Inverted page table는 뭐냐면은 이 접근을 하는게 실제 그 page frame number를 통해서 이걸 접근을 하고 싶은 거고요. 이걸 접근을 하고 싶은 거고 여기에 저장되어 있는 정보들이 어떤 VPN인지가 쭉 저장이 되고요. 이 page frame number를 가르치고 있는 VPN.

여기 반대로 저장하겠다는 거예요. 왜 이렇게 하냐면은 이렇게 왼쪽과 같이 하면은 모든 프로세스에 대한 테이블을 다 구성을 해야 된다라는 문제가 있죠. 그 말은 실제 내가 프레임 너번보다 이 테이블의 개수가 더 많아야 되잖아요. 엔트리 개수가. 그러니까 그 공간이 또 너무 아까우니까 이걸 반대로 하면은 이 페이지 프레임 너버는 딱 정해드렸죠. 그것만큼 여기 알다니는 VPN들을 반대로 관리를 하겠다. 다만 공간이 세일이 되겠죠

근데 보통 우리가 찾아 들어갈 때, vpn에서 찾아 들어갔잖아요. 그래서 운이 나쁘면 이 모든 페이지 프레임 너버를 다 서치해야 하는 워스케이스도 존재한다는 게 이거의 단점이에요. 얘로부터 얘를 우리가 찾아 들어가는데, 얘는 그걸 반대로 관리하니까 공간 효과를 세이브가 되지만,

이거 찾을 때 시간이 많이 걸릴 수 있다는 게 이 멀티페이지 테이블의 단점입니다. 질문! 오케이, 수고하셨습니다.