[OS] Memory Management Scheme

※ 질문/내용오류/공유할 내용이 있다면 jinkilee73@gmail.com으로 메일 주세요 :-)

시스템 프로그래밍 부분에 보면 4~5개에 걸쳐서 Virtual Memory를 설명해놓았다. 이번에는 그 때 설명한 Virtual Memory를 실제로 어떤 식으로 OS에서 관리되고 있는지 확인해보자.

한 가지만 확실히 해두고 설명을 해보려고 한다. 아무리 Virtual Memory가 존재한다 할지라도 반드시 실행하려는 코드는 Physical Memory에 있어야 한다는 어쩌면 원론적이면서도 까먹기 쉬운? 개념이다. 이 말인즉 어떤 코드가 실행되려면 항상 그 코드는 Physical Memory에 있어야 한다는 이야기이다. 반대로 말해보자. 하나의 프로그램에서 실행되지 않아도 되는 코드는 굳이 Physical Memory에 있을 필요가 없다는 뜻도 된다.

위의 내용은 이전의 시스템 프로그래밍 부분에서 포스팅해둔 부분을 잘 읽어봤다면 쉽게 이해할 수 있는 그렇지만 매우 중요한 개념이다. 이 때 간과한 내용이 있는데, 비록 Physical Memory에는 모든 프로그램의 코드가 올라가 있을 필요가 없지만 적어도 Virtual Memory에는 모든 프로그램 코드가 올라가 있어야 한다는 사실이다. 이 사실을 머릿 속에 집어넣고 공부를 다시 해보자.

이번 포스팅에서는 Virtual Memory를 구현하는 방법에 대해서 설명하려고 한다. 가장 대표적인 기법을 설명하려고 한다. 바로 Demand Paging이다. 우선 이 개념을 설명하기 전에 잡고 갈 개념이 바로 Page이다. Page란 무엇인가? Virtual Memory가 일정 크기로 나눠지면 그 하나 하나를 우리는 Page라고 한다. Physical Memory가 일정 크키로 나눠진 하나 하나는 뭐라고 부를까? 정확히 말하면 Page Frame이라고 하고 보통 Frame이라고 불리우나 많은 사람들이 그냥 Page라고 명칭한다. 나는 내 블로그에 포스팅을 할 때 다른 사람들처럼 혼동되게 하기 싫기 때문에 정확한 명칭을 사용하여 블로깅을 하도록 하겠다.

Page와 Frame의 개념을 알았으면 이제 Demand Paging의 개념을 공부해보자. Demand!! 요구하다 라는 뜻이다. Page를 요구하는 것이다. 왜 요구를 하느냐? 프로그램을 실행할꺼니까 요구를 한다. 가령 이와 같은 프로그램을 생각해보자. 4개 중에 하나의 경우만 실행하고 종료하는 프로그램이라고 가정해보자. 이 프로그램을 사용하는 모든 사람들은 4개 중에 하나만 사용하고 끝낼꺼다. 그런데 굳이 전체 프로그램을 Main Memory에 로딩시킬 필요가 있을까? 그렇지 않다. 필요한(요구하는) 하나만 Main Memory에 올리면 된다. (그렇지만 여기서도 기억하자. Virtual Memory에는 전체의 프로그램이 올라가 있어야 한다는 것이다.) 아래의 그림을 보자.

4개의 옵션을 선택하여 실행하고 종료하는 프로그램이라고 가정하자. Virtual Memory에는 모든 프로그램이 전부 로딩되어있다. (이 프로그램의 Virtual Memory의 Page는 A부터 F까지라고 하자.) 이 중 A와 B는 항상 실행되어야 하는 루틴이라고 치고 C, D, E, F가 각각 선택될 4개의 루틴이라고 하자. Main Memory에 로딩되어있는 것을 보니 D만 로딩되어있다. D를 선택했다는 것이다. Demand Paging 기법은 이와 같이 원하는 페이지만 로딩시키는 기법이다. 

갑자기 Page Table이라는 것이 나와서 당황했을 것이다. 잠깐만 설명하고 넘어가자. Virtual Memory에 있는 page가 Main Memory의 Frame으로 변환되려면 page table이 필요하다. A번 Page는 2번으로 mapping 되어있으니까 Page Table에는 2와 A를 한 칸에 놓고 Valid-Invalid bit을 V로 세팅한다. Valid-Invalid Bit은 다음과 같이 세팅된다.

Valid(V) : Virtual Memory의 Page가 Main Memory의 Frame에 존재하고 legal할 때

Invalid(I) : Virtual Memory의 Page가 Main Memory의 Frame에 존재하지 않거나 legal하지 않을 때

페이지 테이블에 관한 이야기는 이 정도로 하자. 다음에 더욱 자세하게 이야기 할 생각이다.

다시 Demand Paging 본론으로 돌아오자. 그래!! 원하는 페이지만 메모리에 로딩해서 사용한다고 하자. 그러면 일단 멀티프로그래밍 수치가 좋아지겠네? 그리고 메모리를 이전보다 훨씬 효율적으로 사용할 수 있겠네? 그런데도 메모리가 꽉 찰 확률은 존재한다. 아래의 그램을 보자.

이와 같이 프로세스 3개를 썼는데 Main Memory가 꽉 차버린 상태에 이르렀다고 해보자. 이 때 새로운 프로세스의 A라는 페이지라 요청이 되었으면 어떤 일이 벌어질까? 이 때 Page Fault가 일어난다. 요청하는 페이지가 메모리에 없는 상황이다. Page Fault는 Memory가 꽉 찬 상황에서만 일어나는 것이 아니다. 꽉 차지 않은 상황이라도 요청하는 페이지가 메모리에 없으면 Page Fault가 생기는 것이다. Main Memory가 꽉 차지 않은 상태에서 Page Fault가 발생하면 아무것도 없는 Free Frame을 하나 선택하여 그 Frame에 Page를 집어넣는다.

새로운 프로세스인 banana.exe는 1번 Frame에 자신의 페이지 B를 넣으려고 한다. 그런데 Main Memory의 Frame 1을 보면 Apple.exe의 페이지 B가 떡 하니 차지하고 있다. 이럴 때 사용하는 것이 Page Replacement Algorithm이다. Main Memory 1~11까지의 프레임 중 하나를 골라서 Banana.exe의 페이지 B와 교체하는 것이다. 

여기서 잠깐, Page Replacement Algorithm에서 가장 대표적인 것은 LRU 정도가 되겠다. Least Recently Used의 약자로 최근에 가장 적게 사용된 페이지를 골라서 교체하는 것이 메모리 효율상 좋다고 생각하고 만들어낸 알고리즘이다. 이 알고리즘에 대한 설명은 나중에 하기로 하자.

Page Replacement가 진행된 후에 어떤 모습이 되는지 알아보자.

그림이 조금 작아졌으나 정성껏 그린 그림이니 잘 봐주길 바란다. 위의 그림에서는 임의로 Orange.exe 프로세스의 Page A를 교체한다고 가정했다. 빨간 네모 쳐진 부분이 변경된 부분이다. 주의할 것은 Orange.exe의 page table을 보라. 이전에는 Frame 5와 Page A가 mapping 되어있었는데 Page Replacement 후에는 그 내용이 Update되었다. 

[Reference : Operating Systems Concept_Steps in handling a page fault]

지금까지 잘 이해했다면 위의 그림을 이해할 수 있어야 한다. Page Fault가 일어났을 때 전체적으로 어떤 작업이 일어나는 것인지 설명하는 그림이다. 추가적으로 조금 설명할 부분이 있다면 4번에서 bring in missing page를 보면 missing page를 free frame에 저장하는데 만일 free frame이 없다면 위에서 설명했던 Page Replacement Algorithm이 사용되는 것이고, 마지막에 instruction을 재시작해주는 과정도 필요하다. 

이것이 바로 Demand Paging 기법이다. 다음 포스팅에서는 Page Table에 대한 이야기 혹은 Least Recently Used Page Replacement Algorithm 기법에 대해서 설명할 예정이다. 어떤 걸 할지는 내 맘이지롱