가상 메모리

스와핑

메모리에 적재된 프로세스 중 오랫동안 사용되지 않거나 입출력 대기를 하는 프로세스들을 보조기억장치로 일부 영역 내쫓고 메모리의 빈 공간에 다른 프로세스를 적재하는 방식. 

• 스왑 영역 : 보조기억장치에서 쫓겨난 프로세스들의 영역
• 스왑 아웃 : 프로세스가 메모리 -> 보조기억장치로 쫓겨남
• 스왑 인 : 보조기억장치 -> 메모리로 다시 복귀

 

스와핑으로 프로세스들의 요구 공간이 실제 메모리 크기보다 커도 실행 가능하게 된다.

free -h 로 스왑영역 확인 가능

 

 

메모리 할당

프로세스의 메모리를 메모리 내에 빈 공간이 여러 개 있다면 어디에 적재하게 될까?

 

1. 최초 적합 방식 : 가장 먼저 발견하는 빈 공간에 적재
2. 최적 적합 방식 : 프로세스를 적재할 수 있는 공간 중 가장 작은 공간에 적재
3. 최악 적합 방식 : 빈 공간 중 가장 큰 공간에 적재

 

외부 단편화

적재를 하다보면 빈 공간들이 있긴 빈 공간이 연속되어 있지 않기 때문에 하지만 프로세스는 적재하지 못하는 현상

 

압축(메모리 조각 모음) : 여기저기 흩어져있는 빈 공간의 메모리를 하나의 큰 빈 공간을 만드는 방법.

하지만 메모리를 옮기는 데에 오버헤드, 시스템이 하던일을 중지해야 하는 등 여러 단점이 있다.

 

그래서 등장한 방법이 ‘페이징 기법’. 연속적으로 할당이 문제가 되었으니 불연속적으로 할당하자.

 

페이징

프로세스의 메모리를 페이지라는 단위로 여러 조각으로 자른다.

메모리의 물리 주소 공간을 프레임이라는 단위로 여러 조각으로 자른다.

페이지를 프레임에 할당한다.

 

그럼 어떻게 프로세스가 불연속적인 메모리에 자유자재로 접근이 가능할까?

-> 논리 주소는 연속적으로 배치하고, 논리 주소의 페이지 번호와 물리 주소의 프레임번호를 매핑한 ‘페이지 테이블’을 이용

(페이지 테이블은 메모리에 저장되어 있다)

-> 논리 주소로 페이지 테이블을 거쳐서 실제 물리 메모리 주소에 접근한다.

 

페이지 아웃, 페이지 인 - 페이지 단위로 스와핑을 함.

=> 프로세스를 실행하기 위해 프로세스 전체가 메모리에 올라갈 필요가 없다는 것을 의미

 

 

내부 단편화

페이지로 자르더라도 페이지 크기 보다 작은 크기로 단편화가 발생할 수 있다.

페이지 크기를 작게하면 단편화의 크기는 줄어들지만 페이지 테이블의 크기가 증가하여 이를 잘 조절하는 것이 중요

getconf PAGESIZE 명령어로 확인 가능

 

페이지 테이블 베이스 레지스터 (PTBR) : CPU내에 각 프로세스의 페이지 테이블 베이스 주소를 저장하는 레지스터

페이지 테이블의 정보들은 각 프로세스의 PCB에 저장되고 문맥 교환이 일어날 때 다른 레지스터와 같은 방식으로 레지스터 교체

 

 

페이지 테이블 사용의 문제

• 메모리를 두번 접근함

-> CPU 옆 MMU (가상 메모리 주소를 실제 메모리 주소로 변환하는) 내부에 TLB (Translation Lookaside Buffer) 라는 페이즈 테이블의 캐시를 둔다.

-> TLB 히트, TLB 미스 개념 존재

 

접근하려는 주소가 페이지 번호와 변위 (offset) 이 프레임 번호와 변위로 변환된다.

 

그럼 페이지 크기와 프레임 크기는 동일한가 ?

=> 동일하다. 동일하기 때문에 변환하고 변위를 더해서 찾을 수 있다.

 

페이지 테이블 엔트리

페이지 테이블에 페이지와 프레임의 번호만 있는 것이 아님

 

유효 비트 : 페이지가 메모리에 적재되어 있을 수도 아닐 수도 있다. 유효 비트로 적재되어 있으면 1 아니면 0

• 유효 비트가 0이면 ‘페이지 폴트’ 발생
• 페이지 폴트가 발생하면 CPU 기존 작업 백업 -> 페이지 폴트 처리 루틴 실행 -> 유효 비트 1로 변경 -> 기존 작업 실행

 

보호 비트 : 1은 읽고 쓰기 가능한 페이지 , 0은 읽기 전용 페이지 . 3개의 비트로 관리도 가능 rwx

 

참조 비트 : 페이지에 접근한 적이 있는지 여부. 적재 이후 읽거나 썼다면 1 아니면 0

수정 비트 : 해당 페이지에 데이터를 쓴적이 있는지 여부. 변경되었다면 1 아니면 0

 

수정 비트는 왜 있을까?

-> 보조기억장치 스왑 영역의 페이지 -> 메모리의 페이지가 되는데 

-> 한번도 수정한 적이 없는 페이지는 스왑 아웃(페이지 아웃)할 때 복사할 필요가 없음. 

 

 

쓰기 시 복사(copy on write) - 페이징의 이점

fork시에 부모 프로세스의 코드,데이터 영역 등 모든 자원이 복제되어 메모리 적재된다고 했는데

 

fork 만 하였을 때도 불필요하게 복제되어 자원이 낭비된다. (e.g. fork 후 쓰지 않고 읽기 작업만 하는 경우)

그래서 copy on write 방식은 자식 프로세스가 부모 프로세의 페이지 테이블만 동일하게 가져간다.

-> 자식 프로세스가 부모 프로세스의 프레임을 가리킨다.

-> 부모 프로세스나 자식 프로세스 둘 중 하나가 쓰기 작업을 하는 순간에 해당 페이지가 별도 공간으로 복제되어 새로운 프레임을 가리킨다.

-> 시간 공간 절약하는 방법

 

 

계층적 페이징

• 페이지 테이블 크기도 생각보다 작지 않다.
• 모든 페이지 테이블을 메모리에 두지 않고 쪼개서 일부는 보조기억장치에 두자.
• 페이지테이블의 테이블을 메모리에 둔다. (다단계 페이지 테이블)

기존에 페이지 번호 + 변위 였다면, 바깥 페이지 번호 + 안쪽 페이지 번호 + 변위의 ‘논리 주소’를 사용한다. (바깥 + 안쪽으로 프레임 번호를 구하는 방식)

 

 

요구 페이징

필요한 페이지만 메모리에 적재하는 기법

양상 

1. CPU가 특정 페이지 접근하는 명령어 실행

2. 해당 페이지가 메모리에 있는 경우(유효 비트가 1인 경우) CPU가 페이지가 적재된 프레임에 접근

3. 페이지 폴트가 발생한 경우(유효 비트가 0인 경우) 페이지 폴트 처리 루틴을 실행하고 유효 비트 1로 설정. 그리고 다시 1을 실행

 

(순수 요구 페이징 : 처음부터 아무것도 메모리에 올리지 않고 실행하여 계속 페이지 폴트 발생하다 빈도가 줄어듦)

 

메모리가 가득 찼을 때 어떤 페이지를 보조기억장치로 내쫓는 것(페이지 아웃)이 좋을까 ? 

-> 페이지 폴트가 가장 적게 발생할수록 좋다.

-> 페이지 참조열을 통해 알아낼 수 있다.

 

페이지 교체 알고리즘

쫓아낼 페이지를 결정하는 방법

1. FIFO : 가장 먼저 메모리에 올라온 페이지를 내쫓음

2. 2차 기회 페이지 알고리즘 : FIFO 에서 기회를 한 번(?)씩 더 준다.

3. 최적 페이지 교체 : 사용 빈도가 가장 낮은 친구를 내쫓는다. 가장 페이지 폴트가 적지만 구현이 어려움.

(앞으로 어떤 페이지를 참조할지 미리 알기 어려움)

4. LRU : 가장 오랫동안 사용되지 않은 페이지를 교체한다. (최근에 사용되지 않은 페이지는 앞으로도 사용되지 않을 것.)

 

 

스래싱과 프레임 할당

사실 프레임 교체 알고리즘이 아니더라도 프로세스가 사용할 수 있는 프레임이 적으면 페이지 폴트가 자주 발생함

 

스래싱 : 프로그램 실행시간보다 페이징 교체하는 시간이 더 많아져서 성능이 저해되는 문제

(CPU 曰: 아니 페이지를 달라고 할 때마다 페이지를 교체하면 나는 언제 실행해...)

 

=> 동시에 실행되는 프로세스를 늘린다고 해서 CPU 이용률이 그만큼 증가하는 것이 아님

(각 프로세스들이 사용하는 프레임 수가 줄어들기 때문에 페이징 폴트가 자주 발생)

 

그럼 프레임 할당을 프로세스에게 얼만큼 하는 게 좋을까?

작업 집합 모델 : 일정 시간동안 주로 참조한 페이지 집합(작업 집합)에 기반하여 할당 

페이지 폴트 빈도 기반 : 페이지 폴트 너무 높다 -> 프레임 적게 할당되었다,  페이지 폴트 너무 낮다 -> 프레임 많이 할당 되었다.

 

프레임 할당을 운영체제가 실행 중에 실시간으로 바꿀 수 있나?

=> 모름. 아마 가능할 듯하다