쓰기 시 복사
- 페이징의 이점 : 외부 단편화 문제 해결, 프로세스 간의 페이지 공유(쓰기 시 복사)
- 이론적인 fork()
- 프로세스는 기본적으로 자원을 공유하지 않음
- 부모 프로세스가 적재된 별도의 공간에 자식 프로세스가 통째로 복제되어 적재
- 그러므로, 프로세스 생성 시간 지연, 메모리 낭비(똑같은게 메모리에 중복해서 저장되므로)
- 쓰기 시 복사
- 부모 프로세스와 동일한 자식 프로세스가 복제되어 생성되면
자식 프로세스는 부모 프로세스와 동일한 프레임을 가리킴 - 쓰기 작업이 없다면 상태 유지 (동일한 프레임 가리킴)
- 부모 프로세스와 동일한 자식 프로세스가 복제되어 생성되면
- 부모 프로세스/자식 프로세스 둘 중 하나가 페이지에 쓰기 작업 수행 시 해당 페이지는 별도의 공간으로 복제
=> 프로세스 생성 시간 절약, 메모리 절약
- 부모 프로세스와 자식 프로세스가 별도의 자원을 유지하면서 중복해서 메모리를 저장하지 않는 방식
- 더 효율적으로 메모리 관리가 가능함
계층적 페이징
- 프로세스 테이블의 크기는 생각보다 작지 않음
- 프로세스의 크기가 커지면 프로세스 테이블의 크기도 커질 수 있음
- 그러므로 프로세스를 이루는 모든 페이지 테이블 엔트리를 메모리에 두는 것은 낭비
- 프로세스를 이루는 모든 페이지 테이블 엔트리를 항상 메모리에 유지하지 않을 방법이 필요!
계층적 페이징
- 페이지 테이블을 페이징하여 여러 단계의 페이지를 두는 방식
- = 다단계 페이징 = 멀티 레벨 페이징
- 페이지 테이블을 여러 페이지로 쪼개고, 이 페이지를 가리키는 페이지 테이블(Outer 페이지 테이블)을 두는 방식
- 최상단 페이지 테이블(Outer Page Table)은 반드시 메모리에 유지,
그 외에는 지금 당장 써야하는 일부 페이지 테이블만 메모리에 적재 - 이로써 모든 페이지 테이블을 항상 메모리에 둘 필요가 없어짐
- CPU와 가장 가까이 위치한 페이지 테이블(Outer 페이지 테이블)만 항상 메모리에 유지
계층적 페이징을 이용하는 환경에서의 논리 주소
- 논리 주소는 페이지 번호와 변위로 구성
- 계층적 페이징에서는 페이지 번호가 "바깥 페이지 번호, 안쪽 페이지 번호" 이런식으로 페이지 번호가 여러개로 구성
- 이용 예시
- 계층이 너무 많아지면 부작용 발생
- 페이지 폴트(참조하고자 하는 페이지가 현재 메모리에 없는 상태)가 발생했을 때, 여러번의 메모리를 참조해야 함
- 그러므로 계층이 많다고 무조건 빠르고 좋다고 할 순 없음
페이지 교체와 프레임 할당
- 물리 메모리보다 큰 프로세스를 실행할 수 있지만, 그럼에도 물리 메모리의 크기는 명확히 한정되어 있으므로 운영체제 입장에서 다음 두가지 문제를 반드시 해결해야 함
- 기존에 적재된 불필요한 페이지를 선별해 보조기억장치로 내보내고 => 페이지 교체
- 프로세스들에게 적절한 수의 프레임을 할당 => 프레임 할당
요구 페이징(Demand Paging)
- 처음부터 모든 페이지를 적재하지 않고 필요한 페이지만을 메모리에 적재하는 기법
- 즉, 요구되는 페이지만 적재하는 기법
- 요구 페이징이 실행되는 양상
- 요구 페이징 시스템이 안정적으로 작동하려면 해결해야하는 문제
- 페이지 교체
- 프레임 할당
- 참고) 순수 요구 페이징
- 아무런 페이지도 메모리에 적재하지 않은 채 일단 무작정 실행부터 해버리는 방법
- 명령어를 실행하는 순간부터 페이지 폴트가 계속 발생, 실행에 필요한 페이지가 어느정도 적재된 이후에는 페이지 폴트 발생 빈도 감소
페이지 교체 알고리즘
- 요구 페이징 기법으로 페이지들을 적재하다보면 언젠간 메모리가 가득 차게 됨
- 당장 실행에 필요한 페이지를 적재하려면 적재된 페이지를 보조기억장치로 내보내야 함
- 이때, 어떤 페이지를 내보낼지 결정하는 방법 => 페이지 교체 알고리즘
- 무엇이 좋은 페이지 교체 알고리즘일까?
=> 페이지 폴트가 적은 알고리즘이 좋은 알고리즘- 페이지 폴트가 발생하면 보조기억장치에 접근해야 해서 성능 저하
- 어떤 페이지를 스왑 아웃했을 때 페이지 폴트가 많이 발생하면 안좋은 알고리즘, 페이지 폴트가 적게 발생하면 좋은 알고리즘
- 페이지 폴트 횟수 확인 방법 : 페이지 참조열(page reference string)
- CPU가 참조하는 페이지들 중 연속된 페이지를 생략한 페이지열
- 연속된 페이지는 페이지 폴트가 발생하지 않기 때문
2 2 2 3 5 5 5 3 3 7
↓ 위 항목의 페이지 참조열
2 3 5 3 7
FIFO 페이지 교체 알고리즘
- 오래 머물렀으면 나가라!
- 메모리에 가장 먼저 올라온 페이지부터 내쫓는 가장 단순한 방식
- First In First Out
- 단점
- 프로그램 실행 초기에 잠깐 실행될 페이지 => 문제 X
- 프로그램 실행 내내 사용될 페이지 => 먼저 적재되었다는 이유로 내쫓으면 페이지폴트 빈번하게 발생
- 보완책 : 2차 기회(second-chance) 페이지 교체 알고리즘
- 참조 비트 1
- CPU가 한 번 참조한 적이 있는 페이지
- 한 번 더 기회를 주기(참조 비트 0으로 초기화 후 적재 시간을 현재 시간으로 설정)
- 참조 비트 0
- CPU가 참조한 적이 없는 페이지
- 내쫓기
- FIFO 알고리즘과 마찬가지로 메모리에서 가장 오랫동안 머물렀던 페이지를 쫓아냄
- 하지만, 만약 페이지 참조비트가 1이면 바로 내쫓지 않고 적재된 시간을 현재 시간으로 설정하고 다시 맨끝으로 보냄
- 만약 가장 오래 머문 페이지인데 참조비트가 0이면 바로 내보냄
- 참조 비트 1
최적 페이지 교체 알고리즘
- CPU에 의해 참조되는 횟수를 고려
- 메모리에 오래 남아야 할 페이지는 자주 사용될 페이지
- 메모리에 없어도 될 페이지는 오랫동안 사용되지 않을 페이지
- 그러므로 앞으로의 사용 빈도가 가장 낮은 페이지를 교체하는 알고리즘
- 가장 낮은 페이지 폴트율을 보장하는 페이지 교체 알고리즘
- 하지만, 앞으로의 상황을 알 수가 없기 때문에 실제 구현이 어려움
- "앞으로 오랫동안 사용되지 않을 페이지를 어떻게 예측할 것인가?
- 따라서, 다른 페이지 교체 알고리즘의 성능을 평가하기 위한 하한선으로 간주
(최적 페이지 교체 횟수와 다른 알고리즘의 교체 횟수를 비교하여 성능 평가)
LRU(Least-Recently-Used) 페이지 교체 알고리즘
- 최적 페이지 교체 알고리즘 : 가장 오래 사용되지 않을 페이지 교체
- LRU 페이지 교체 알고리즘 : 가장 오래 사용되지 않은 페이지 교체
- "최근에 사용되지 않은 페이지는 앞으로도 사용되지 않지 않을까?"
- 그러니까, 가장 오래 사용되지 않은(최근에 적게 사용된, 최근 사용이 적은) 페이지를 교체하자!
추가) LFU(Least-Frequently Used) 페이지 교체 알고리즘
- 가장 사용이 적은 페이지를 교체하는 기법 (사용 빈도가 적은 페이지 교체)
스래싱과 프레임 할당
- 페이지 폴트가 자주 발생하는 이유
- 나쁜 페이지 교체 알고리즘
- 하나의 프로세스가 사용할 수 있는 프레임 수 자체가 작은 경우
- 페이지폴트가 자주 발생하면 CPU의 이용률도 감소하게 됨
- CPU가 쉴 새 없이 프로세스를 실행해야 컴퓨터의 전체적인 생산성도 올라가는데, 페이지 교체에 너무 많은 시간을 쏟으면 컴퓨터의 성능이 저하됨
스래싱(Thrashing)
- 프로세스가 실행되는 시간보다 페이지 교체에 더 많은 시간을 소요해서 성능이 전체적으로 저하되는 문제
- 즉, 지나치게 빈번한 페이지 교체로 인해서 CPU 이용률이 낮아지는 문제
- 세로축(CPU 이용률) : CPU가 얼마나 쉴새없이 일하고 있는지
- 가로축(멀티 프로그래밍의 정도) : 메모리에 동시에 실행되고 있는 프로세스의 수
- 동시에 실행되고 있는 프로그램의 수가 많다고 해서 반드시 CPU 이용률이 그에 비례하여 높아지는 것은 아님
- 어느정도 이상으로 동시에 실행되는 프로세스 수가 많아지면 CPU 이용률이 현저히 감소함(스레싱이 발생한 지점)
- 스레싱이 발생하는 이유
- 각 프로세스가 필요로 하는 최소한의 프레임 수가 보장되지 않았기 때문
- 예를 들어, 프로세스 A의 최소 프레임 수가 10개인데 5개의 프레임만 할당하면 페이지 폴트가 자주 발생, 스레싱이 발생할 위험 상승
- 그러므로, 각 프로세스가 필요로 하는 최소한의 프레임 수를 파악하고, 프로세스들에게 적절한 프레임을 할당해주어야 함
- 각 프로세스가 필요로 하는 최소한의 프레임 수가 보장되지 않았기 때문
균등 할당(equal allocation)
- 가장 단순한 할당 방식
- 모든 프로세스들에게 균등하게 프레임을 할당하는 방식
- 예를 들어 300개의 프레임을 가지고 있고, 현재 3개의 프로세스가 동시에 실행중에 있다면 각각 100개의 프레임을 할당해주는 방식
- 단순하지만, 실행되는 프로세스들의 크기가 각기 다른데, 크던 작던 무조건 동일한 프레임 수를 할당하는 것은 비합리적
비례 할당(proportional allocation)
- 프로세스 크기에 비례하여 프레임 할당
- 프로세스 크기가 크면 프레임 많이 할당, 프로세스 크기가 작으면 프레임 조금 할당
- 정적 할당 방식 : 균등 할당, 비례 할당
- 프로세스의 실행 과정을 고려하지 않고 프로세스나 물리메모리의 크기만 고려한 방식
- 한계
- 크기가 큰 프로세스여도 막상 실행될 땐 프레임을 적게 사용할 수 있음
- 마찬가지로 크기가 작은 프로세스여도 실행해보면 많은 프레임을 필요로 할 수 있음
- 결국 프로세스가 필요로 하는 프레임 수는 실행해봐야 알 수 있음
작업 집합 모델(working set model)
- 프로세스가 실행하는 과정에서 배분할 프레임 결정(동적 할당 방식)
- 스레싱이 발생하는 이유는 빈번한 페이지 교체 때문
- 그렇다면 CPU가 특정 시간 동안 주로 참조한 페이지 개수만큼만 프레임을 할당하면 됨!
- 작업 집합 : 실행 중인 프로세스가 일정 시간 동안 참조한 페이지의 집합
- 즉, 프로세스가 일정 기간 동안 참조한 페이지 집합을 기억하여 빈번한 페이지 교체를 방지
- CPU의 참조 지역성의 원리와 비슷
- CPU가 메모리를 참조할 땐 참조 지역성의 원리에 의거하여 주로 비슷한 구역을 집중적으로 참조하는 것과 비슷
- 어떤 프로세스가 100개의 페이지로 이루어져 있다고 해서 반드시 그 100개의 페이지를 모두 고르게 참조하는 것은 아님
- 특정 시간 동안 집중적으로 몇몇의 페이지만을 참조함
- 그러므로 CPU가 특정 시간 주로 참조한 페이지 개수만큼만 프레임을 할당
- 예를 들어, 3초라는 시간 동안 7개의 페이지를 집중적으로 참조했다면 운영체제가 7개의 프레임을 할당
- 작업 집합 모델을 구하려면 아래 두가지가 필요
- 프로세스가 참조한 페이지 : 프로세스가 어떤 페이지를 참조했는가?
- 시간 간격 : 어떤 시간 간격 동안에 참조한 페이지를 구할 것인가?
페이지 폴트 빈도
- 프로세스가 실행하는 과정에서 배분할 프레임 결정(동적 할당 방식)
- 두 개의 가정에서 생겨난 아이디어
- 페이지 폴트율이 너무 높으면 그 프로세스는 너무 적은 프레임을 갖고 있다.
- 페이지 폴트율이 너무 낮으면 그 프로세스는 너무 많은 프레임을 갖고 있다.
- 페이지 폴트율과 할당된 프레임의 수는 반비례 관계
- 페이지 폴트율의 상한선과 하한선을 정하고 이 범위 안에서만 프레임을 할당하는 방식
- 페이지 폴트율이 너무 높으면 그 프로세스는 너무 적은 프레임을 갖고 있다.
=> 상한선. 프레임 추가 할당 - 페이지 폴트율이 너무 낮으면 그 프로세스는 너무 많은 프레임을 갖고 있다.
=> 하한선. 프레임 회수
- 페이지 폴트율이 너무 높으면 그 프로세스는 너무 적은 프레임을 갖고 있다.
출처 : 혼자 공부하는 컴퓨터구조 + 운영체제 (저자 강민철)
'취업역량강화 > 컴퓨터공학' 카테고리의 다른 글
| [운영체제] 파일과 디렉터리, 파일 할당과 파일 시스템 (1) | 2026.02.27 |
|---|---|
| [운영체제] 가상 메모리 (연속 메모리 할당, 페이징을 통한 가상 메모리 관리) (0) | 2026.02.23 |
| [운영체제] 교착 상태와 해결 방법 (0) | 2026.02.21 |
| [운영체제] 프로세스 동기화(뮤텍스 락, 세마포, 모니터) (0) | 2026.02.19 |
| [운영체제] CPU 스케줄링과 스케줄링 알고리즘 (0) | 2026.02.17 |