TLB
TLB: 자주 사용되는 주소 변환 정보를 빠르게 참조할 수 있게 하는 캐시 메모리.
TLB가 어떻게 페이지 테이블 성능을 향상시키는가?
TLB miss가 발생하면 시스템이 어떤 과정을 거쳐 메모리에 접근하는가?
TLB에 원하는 주소 변환 정보가 있으면 페이지 테이블 참조하지 않고 바로 물리적 주소를 얻을 수 있다.
TLB miss => CPU가 TLB를 조회했으나 필요한 페이지 테이블 엔트리가 없는 경우
페이지 테이블을 조회
=> 페이지 테이블 엔트리가 유효하지 않거나 해당 페이지가 메모리에 없는 경우page fault 발생 시- 디스크에서 해당 페이지 메모리로 로드하고 페이지 테이블 업데이트, 새로 로드된 페이지에 대한 물리적 프레임 할당
=>page fault 가 발생하지 않는 경우- 이미 페이지 테이블에 유효한 엔트리가 있음페이지 테이블 업데이트 후
TLB 업데이트: 페이지 테이블에서 얻은 최신 변환 정보를 TLB에 업데이트
Belady's Anomaly
페이지 프레임 수를 늘리는데도 page fault가 발생하는 빈도가 증가하는 현상
이러한 현상이 발생하는 원인과 이를 방지하는 해결 방법?
FIFO 페이지 교체 알고리즘에서 관찰됨
FIFO: 가장 오래된 페이지를 교체. 메모리에 가장 먼저 들어온 페이지를 메모리에서 제거하고 새 페이지를 그 자리에 삽입 -> 페이지의 사용 빈도나 중요도를 전혀 고려 안함. =>
-> 실제로는 자주 사용되는 페이지가 교체될 수 있고, 그 결과 페이지 폴트가 더 자주 발생한다.
왜 페이지 프레임의 수가 증가함에도 page fault가 증가하는가?
- 페이지의 실제 사용 빈도나 필요성과는 무관하게 페이지 교체 대상이 결정됨
- 페이지 프레임 수가 증가하면 이론적으로는 Page fault가 줄어들어야 하지만
FIFO는 새로운 페이지가 오래된 페이지보다 덜 필요한 상황을 고려하지 않음 - 실제로 자주 접근되는 페이지임에도
FIFO에서는 교체될 위험이 있음 => 프레임 수가 증가함에도 불구하고 page fault가 증가하는 원인 - 특정 순간에 메모리에 적재되어야 하는 최적의 page set
=> FIFO 에선 최적의 Page set에 도달하기 위해 더 많은 페이지 교체가 필요 - 비효율적
이를 해결하려면?
더 진보된 페이지 교체 알고리즘 -LRU, LFU 알고리즘
=> 페이지를 교체할 때 단순히 페이지의 로드 시간뿐만 아니라 사용 빈도나 최근 사용 기록을 고려한다.
=>locality개념에 기반한 제약을 가미하고 교체/할당 정책을 보완하는 것이 해결 방안이 될 수 있다.
Thrashing
: 프로세스가 너무 자주 페이지를 교체,
주로 가상 메모리 시스템에서page fault가 너무 빈번하게 발생하는
-> 실제 유용한 작업보다 페이지 교체하는 데 더 많은 시간을 소비하는 현상
-> 일반적으로 메모리가 포화 상태이고 멀티 태스킹 환경에서 너무 많은 프로세스가 동시에 실행될 때 발생함
Thrashing 완화 방법
- 적절한 멀티 태스킹 => 동시에 실행되는 프로세스의 수를 조절해서 각 프로세스가 적절한 양의 메모리를 사용할 수 있도록
- 효율적인 페이지 교체 알고리즘: LRU와 같은 알고리즘을 사용하여 page fault 최소화
- 프로그램의 locality 향상 -> 연속적인 메모리 접근 유도
:Working set: 자주 참조되는 페이지들을 묶어서 필요한 페이지들이 메모리에 계속 유지될 수 있도록
운영체제가 anonymous page를 0으로 초기화하는 이유?
anonymous page
: 프로세스에 의해 동적으로 할당되는 메모리 페이지 - 이전에 다른 프로세스에 의해 사용되었을 가능성이 있음
=> 0으로 초기화하지 않으면 새로운 프로세스가 이전 프로세스의 데이터에 접근할 수 있는 보안의 취약점 발생 가능
Clock Algorithm
