1. 프로세스와 가상 메모리
모든 프로세스는 자신만의 가상 주소 공간을 가지고 있다.
32비트/64비트 프로세스는 각 비트수에 맞게 최대 4GB/16GB의 주소 공간을 가진다.
모든 프로세스들은 자신만의 주소 공간을 가지기 때문에,
특정 프로세스 내에서 쓰레드가 수행될 때 해당 쓰레드는 프로세스가 소유하고 있는 메모리에 대해서만 접근이 가능하다. 다른 프로세스에 의해 소유된 메모리는 숨겨져 있으며, 접근이 불가능하다.
윈도우에서는 운영체제 자체가 소유하고 있는 메모리 또한 숨겨져 있다.
이는 특정 프로세스의 수행 중인 쓰레드가 운영체제의 데이터에 접근하는 것이 불가능함을 의미한다.
가상 메모리는 프로세스의 logical memory와 physical memory를 분리하기 위해 만들었다.
이를 이용하여, logical memory가 physical memory보다 커지는 것을 가능케 할 수 있다.
하나의 프로세스 logical memory가 physical memory보다 커지는 것도 가능하며,
여러 프로세스의 logical memory 총합이 physical memory보다 커지는 것도 가능한 것이다.
이처럼, 프로세스가 실제 필요로 하는 부분만 메모리로 올리는 Demand-Paging 기법을 사용한다.
이를 기억해두기 위해 최근의 운영체제들은 디스크 공간을 메모리처럼 활용할 수 있는 기능을 가지고 있다.
디스크 상에 존재하는 이러한 파일을 paging file (또는 swap file)이라고 하며,
모든 프로세스가 사용할 수 있는 가상 메모리로 사용된다.
여기서 말하는 하드 스왑이라는 페이징 파일에서 실제 물리 메모리로 올리고 내리고 하는 일련의 작업을 이야기하는 것이다. 애플리케이션 관점에서 보면, 페이징 파일을 사용하면 애플리케이션이 사용할 수 있는 램의 크기가 증가한 것과 같은 효과를 가져온다. 만일 PC에 4GB의 램이 있고, 디스크 상에 4GB의 페이징 파일이 있다면, 수행 중인 애플리케이션은 PC에 8GB의 램이 있는 것과 동일한 효과를 누릴 수 있다.
한정된 물리 메모리의 한계를 극복하고자 디스크와 같은 느린 저장장치를 활용해,
애플리케이션들이 더 많은 메모리를 활용할 수 있게 해 주는 것이 가상 메모리이다.
2. 프로세스 가상 주소 공간의 분할
각 프로세스의 가상 주소 공간은 분할되어 있으며, 각각의 분할 공간을 파티션(partition)이라고 한다.
주소 공간의 분할 방식은 운영체제의 구현 방식에 따라 서로 다를 수 있으며,
윈도우 계열에서도 커널이 달라지면, 그 구조가 조금씩 달라지곤 한다.
처음 32비트 프로세스는 4GB의 주소 공간을 가질 수 있다고 했다.
하지만, 사용자가 이 4GB를 모두 사용할 수 있는 것은 아니고, 약 2GB밖에 사용하지 못한다.
32비트 주소 공간이 아래와 같이 분할되어 있기 때문이다.
Null 포인터 할당 파티션 : 0x00000000 ~ 0x0000FFFF
유저 모드 파티션 : 0x00010000 ~ 0x7FFEFFFF
64KB 접근 금지 파티션 : 0x7FFF0000 ~ 0x7FFFFFF
커널 모드 파티션 : 0x80000000 ~ 0xFFFFFFFF
1) Null 포인터 할당 파티션
프로그래머가 NULL 포인터 할당 연산을 수행할 경우를 대비하기 위해 준비된 영역이다.
만일 프로세스의 특정 쓰레드가 이 파티션에 대해 읽거나 쓰기를 시도하게 되면 접근 위반(access violation)이 발생한다.
2) 유저모드 파티션
프로세스의 주소 공간 내에서 유일하게 자유롭게 활용될 수 있는 파티션이다.
0x00010000 ~ 0x7FFEFFFF의 범위이므로, 2047MB의 크기이다.
모든 애플리케이션에 대해 프로세스가 유지해야 되는 대부분의 데이터가 저장되는 영역이며,
.exe / .dll 파일이 이 파티션에 로드된다.
3. Page
Page란, 가상 메모리를 사용하는 최소 크기 단위이다.
최근의 윈도우 운영체제는 모두 4096 (4KB)의 페이지 크기를 사용한다.
만약, 페이징 파일에서 물리 메모리로 데이터를 로드할 때,
아무 위치에나 필요한 크기 만큼(무작위) 로드한다고 가정을 해 보자.
이런 경우, 로드하고 언로드하는 데이터의 크기가 모두 달라서,
이를 반복하다 보면 메모리 공간에 fragmentation이 발생하게 된다.
결국 메모리는 남아 있지만, 정작 원하는 크기의 데이터를 물리 메모리로 로드하지 못하게 되는 상황이 생길 수 있는 것이다.
이를 막기 위해, 운영체제가 만든 것이 page라는 최소 크기 단위인 것이다.
4. Demanding-Page
Demanding-page는 실제로 필요한 page만 물리 메모리로 가져오는 방식을 이야기한다.
필요 page에 접근하려 하면, 결국 가상 메모리 주소에 대응하는 물리 메모리 주소를 찾아내어,
물리 메모리 주소를 얻어와 하는데, 이 때 필요한 것이 페이지 테이블(page table)이다.
페이지 테이블에 valid bit 라는 것을 두고, 해당 page가 물리 메모리에 있으면 set, 그렇지 않으면 invalid로 설정한다.
5. page fault
프로그램이 자신의 주소공간에는 존재하지만 시스템의 RAM에는 현재 없는 데이터나 코드에 접근 시도하였을 경우 발생하는 현상이다. 페이지 폴트가 발생하면 운영 체제는 그 데이터를 메모리로 가져와서 마치 페이지 폴트가 전혀 발생하지 않은 것처럼 프로그램이 계속적으로 작동하게 해준다.
<페이지폴트 처리과정>
Page 접근 요청을 하였는데, physical memory에 없는 상태,
즉 valid bit가 clear 되어있는 상황을 Page fault 라 하며 아래와 같은 처리 과정을 거친다.
1) 페이징 하드웨어는 page table entry를 보고 invalid인 것을 확인한 후 OS에게 trap으로 알린다.
2) OS는 정말로 메모리에 없는 것인지 아니면 잘못된 접근인지 확인한 후 잘못된 접근이었으면 종료시킨다.
3) Empty frame (free page)을 얻는다.
4) Page를 frame으로 swap한다.
5) 프로세스의 page table과 TLB를 page-in/page-out 된 것을 토대로 재설정한다.
6) Page fault를 야기했던 인스트럭션부터 다시 수행한다.
3번 과정에서 empty frame을 얻어와야 하는 상황에서 물리 메모리가 이미 모두 사용중이라면,
그 사용중인 frame 중 하나를 선택해서 page-out (페이징 파일로 이동) 시키고, 그 frame을 사용해야 한다.
이와 같이 victim frame을 선택하는 과정에서 Page Replacement Algorithm을 사용한다.
5. 페이지 교체 알고리즘
1. FIFO
가장 먼저 page-in 되어, 오래된 page를 page-out 시키는 방식.
단순하고 깔금하나, memory locality 측면에서는 좀 아니다.
2. LRU (Least Recent Used)
가장 오랫동안 사용되지 않았던 녀석은 앞으로도 사용되지 않을 것이라는 기대로 page-out 시키는 방식.
LRU는 두 가지 방식으로 보통 구현하는데, 카운트 방식 : 4. Counting에서 이 방식을 쓴다.
스택 방식 : 그 많은 페이지를 관리하기 위해, doubly-linked-list를 차용한 스택을 쓰기엔 메모리, 연산량이 아깝다.
3. LRU approximation
LRU 개념이긴 하지만, 하드웨어의 도움을 받아 reference bit을 사용한다.
페이지들을 circular queue 형태로 나타내고 만약 reference가 일어나면 이 bit 를 set 한다.
그리고 victim 페이지를 선정할 때는 하나씩 접근하여 reference bit 를 확인한다.
만약 bit 가 clear하면 그 페이지를 victim으로 선정하며, set 되어 있으면 그 bit 를 clear시키고 다음 페이지를 확인한다. 해당 페이지에 Second-chance를 주는 것이므로 Second-chance algorithm이라고도 한다.
이 방식이 가장 많이 사용되고 효율이 좋은 것으로 알려져 있다.
4. Counting
Page가 참조될 때마다 카운팅을 하는 방식
MFU : Most frequent used
LFU : Least frequent used
5. Thrashing
가상 메모리를 사용하다 보면 실제 물리 메모리 공간보다 논리적 메모리 공간이 큰 것 처럼 사용될 수 있기 때문에 효율적이다.
그런데, 효율적이라는 이유로 멀티 프로세싱의 degree를 계속 늘리다 보면,
실제 실행하는 시간보다 page replacement를 하는 시간이 더 많아지는 순간이 오며, 결국엔 CPU 사용율이 떨어지게 된다. 하드웨어가 엄청많이 돌아가게된다.
이와 같이 프로그램을 제대로 수행하지 못하고, 실행 시간보다 페이지 교체 시간이 많아지는 현상을 Thrashing이라 한다.
이 thrashing이 발생하는 이유는 locality의 크기의 합이 실제 메모리의 크기보다 커졌기 때문이다.따라서, 이 thrashing을 해결하기 위해서, Working set model 이란 것을 적용한다.
Working set model 은 locality 를 approximate한 것으로 페이지 넘버로 관리한다.그러다 working set의 크기가 실제 메모리보다 커지면 하나의 프로세스를 종료하는 방식으로 thrashing이 생기지 않도록 할 수 있다.하지만, 위 방법은 접근되는 페이지를 관리해야 하므로 불편한 감이 있다.따라서, thrashing이 생겼다는 것은 즉, Page fault 가 많아졌다는 것이기 때문에 그것의 정도를 지정하고 Page fault 의 횟수가 어느 한계점을 넘어가면 프로세스를 종료하는 방식으로 구현한다.
그래서 가장 좋은 Thrashing 해결방안은 Thrashing이 발생할 때 가장 좋은 솔루션은 램을 추가로 설치하는 것이다.
7. 가상 메모리의 부가 장점
가상 메모리를 사용하면서 생기는 부가 장점으로 다음과 같은 것들이 있다.
- 공유 메모리 사용
- Copy-on-write 메커니즘
- Memory mapped file
1. 공유 메모리 사용
여러 프로세스 간의 communication의 한 가지 방법으로 공유 메모리를 사용할 수 있는데,
demand-paging 기법을 사용할 경우 다른 프로세스의 각각의 페이지가 같은 프레임을 가리키도록 하면 공유 메모리를 사용할 수 있다.
윈도우의 dll이나 리눅스의 so 역시 이 방식으로 물리 메모리 프레임을 같이 가리키게 하여, 전체 메모리를 절약하게 되는 것이다.
아래 그림에서 프로세스 A의 1번 페이지, 프로세스 B의 7번 페이지가 물리 메모리 5번 프레임을 같이 가리키는 것을 볼 수 있다.
2. Copy-on-write 메커니즘
부모 프로세스를 clone하여 자식 프로세스를 생성하였을 때,
처음에는 같은 메모리를 사용하도록 하다가 그곳에 Write가 발생하였을 때 메모리를 copy하는 것으로 이것 또한 공유 메모리처럼 같은 프레임을 가리키도록 하였다가 복사가 되었을때 새로운 프레임을 할당하면 된다.
3. Memory mapped file
메모리 맵 파일 기능은 가상 메모리처럼 프로세스 주소 공간을 예약하고,
예약한 영역에 물리 저장소를 commit하는 기능을 제공한다.
가상 메모리와 유일한 차이점이라면, 시스템의 페이징 파일을 사용하는 대신
디스크 상에 존재하는 어떤 파일이라도 물리 저장소로 사용 가능하다는 점이다.
메모리 맵 파일은 아래 세 가지 목적으로 사용될 수 있다.
- - 실행 파일(.exe)과 DLL 파일을 읽고 수행
- - 디스크에 있는 데이터에 접근
- - 동일 머신에서 수행중인 다수의 프로세스 간 데이터 공유
출저: 수까락에 프로그래밍 이야기
