페이지 테이블 접근 시 TLB가 어떻게 페이지 테이블의 성능을 향상시키는가?
- TLB는 자주 사용되는 주소 변환 정보를 빠르게 참조할 수 있도록 하는 "캐시 메모리" 이다.
- TLB에 원하는 주소 변환 정보가 있으면, 페이지 테이블을 참조하지 않고 바로 물리적 주소를 얻을 수 있어 성능이 향상된다.
TLB Miss일 때 시스템은 어떤 과정을 거쳐 메모리에 접근하는가?
- TML Miss일 때 시스템은 페이지 테이블을 조회하여 물리적 주소를 찾은 후, 추후 빠르게 접근할 수 있도록 정보를 TLB에 업데이트한다.
Belady의 역설(Belady's Anomaly)
- 페이징 기법을 사용하는 메모리 관리 시스템에서, 프레임 수를 늘리는데도 page fault가 발생하는 빈도가 늘어나는 현상
Belady의 역설이 발생하는 원인
- FIFO 알고리즘에서 자주 관찰된다.
- 프레임 수가 증가함에도 불구하고, FIFO는 오래된 페이지가 새로운 페이지보다 더 많이 필요할 수 있는 상황을 고려하지 않는다. ( 자주 사용되는 페이지도 교체해 버린다 )
- 자주 사용되는 페이지가 교체될 수 있기 때문에, page fault가 더 자주 발생한다.
Belady의 역설 해결방안
- FIFO보다 진보된 페이지 교체 알고리즘을 사용해야 한다. 즉, Locality(지역성) 개념에 기반한 제약을 가미해야 한다.
- LRU, LFU 등의 알고리즘은 페이지의 사용 빈도, 최근 사용 기록을 고려하기 때문에 자주 사용되는 페이지가 메모리에 오래 남아 있을 수 있다. 따라서 Belady의 역설 상황은 일반적으로 발생하지 않게 된다.
- Clock 알고리즘으로도 예방할 수 있다. 그러나 Clock은 LRU의 근사 버전으로써, LRU만큼 완벽하게 Belady 역설 상황을 방지한다고 말하긴 어렵다. 하지만 LRU에 비해 부족한 것이지 Clock 알고리즘도 충분히 Belady 역설 상황을 효과적으로 방지할 수 있다.
스레싱(Thrashing)
- 프로세스가 너무 자주 페이지를 교체하여, 실제 작업보다 페이지 교체에 더 많은 시간을 소비하는 현상
- 일반적으로 메모리가 포화 상태이거나, 멀티태스킹 환경에서 너무 많은 프로세스가 동시에 실행될 때 발생한다.
운영체제가 Anonymous Page를 0으로 초기화하는 이유?
- Anonymous Page는 디스크에 저장되어 있지 않은, 즉 잠시 사용되거나 동적 할당되는 영역인 Stack이나 Heap에서 자주 관찰된다. File-Backed page는 디스크에서 파일을 불러와 수정하거나 실행하지만, Anonymous Page는 디스크 값이 필요가 없기 때문에 (Garbage 값인 것이다) 0으로 초기화하는 작업이 필요하다. 또한 이 작업은 Demand Paging의 일부로 볼 수 있다.
- 또한, Garbage 값을 0으로 초기화하지 않고 사용하게 된다면 새로운 프로세스가 이전 프로세스의 데이터에 접근하는 보안 취약점이 발생할 수 있다.
Dirty Page
Dirty Page란 메모리에 올라와 있는 동안 수정된 페이지. 파일 시스템에 매핑된 File-Backed Page가 수정되었다면, 그 페이지는 "Dirty" 상태가 된다.
Dirty Page의 처리
- File-Backed Page가 수정되어 Dirty 상태가 되고, 그 후 메모리에서 eviction되어야 할 상황이 온다면, 이 페이지는 원래의 디스크에 다시 쓰여진다. 즉, 변경사항이 해당 파일에 반영된다.
- 수정된 내용이 디스크에 저장된 파일에 반영되므로, 메모리가 부족하거나 다른 이유로 페이지를 eviction해야 할 때 변경사항이 손실되지 않는다.
예외 상황
- 만약 File-Backed Page가 읽기 전용으로 매핑되어 있었다면, 수정될 수 없으므로 Dirty 상태가 될 수 없다.
- Anonymous Page의 경우, 디스크의 파일과 연관되지 않으므로 수정된 내용이 메모리에서 eviction되면 스왑 영역으로 이동한다. 이때의 변경사항은 swap 영역에 저장된다.
의문 : 그렇다면 사용자가 아직 저장 버튼을 누르지 않았음에도, 운영체제는 디스크에 파일 변경 사항을 eviction 될 때마다 계속해서 저장하고 있는가?
-> 임시 파일을 사용하거나, 내부 버퍼를 사용해서 “저장”버튼을 누르기 전 까지 최종적으로 디스크에 반영하지 않는다.
임시 파일을 사용하는 방식
- 사용자가 문서나 이미지 등을 편집할 때 애플리케이션은 임시 파일을 생성한다. 이 파일은 원본파일을 복사하거나 변경 사항을 저장하는데 사용된다.
- 사용자가 작업을 하면서 발생하는 변경 사항은 임시 파일에 저장되고 원본 파일을 변경되지 않는다
- 사용자가 저장을 요청하면 변경 사항이 원본 파일에 반영된 후 임시파일은 삭제된다.
내부 버퍼를 사용하는 방식
- 애플리케이션은 메모리 내에 내부 버퍼를 생성한다.
- 사용자가 작업을 진행하면서 생기는 모든 변경 사항은 버퍼에 저장된다. 특히 텍스트 편집기, 코드 에디터에서 많이 사용된다.
- 사용자가 저장 버튼을 누르면 변경 사항이 파일에 기록되며, 버퍼는 초기화된다.
Supplemental Page Table(SPT)
- 페이지 테이블에게 각 페이지에 대한 추가 정보(메타데이터)를 제공하여, 페이지 테이블을 보완한다.
- 페이지 테이블에 메타데이터를 직접 쓰지 않는 이유는 페이지 테이블 형식의 제한 때문이다.
- 단 한번도 물리 메모리와 매핑되지 않은 페이지라도, SPT엔 메타데이터가 저장되어 있다.
의문 : 페이지에 어떤 데이터가 필요할 줄 알고 어떻게 미리 메타데이터를 SPT에 저장하나?
-> 해당 페이지에 어떤 데이터가 필요할지 알 수 있는 이유는, 운영 체제가 프로세스의 실행과 메모리 접근 패턴을 관리하고 있기 때문이다.
1. 프로그램 실행 시
- 실행 파일의 구조를 분석하여 코드, 데이터, 힙, 스택 등 각 세그먼트 위치와 크기 정보를 얻는다. 이 정보를 기반으로 필요한 메타데이터를 SPT에 저장한다.
2. 동적 메모리 할당 시
- 몇 바이트를 어디서 할당할 지 미리 정해둔 후, 실제로 할당하진 않고 SPT에 메타데이터만 저장해둔다
3. 파일 매핑 시
- mmap을 사용하여 파일을 메모리에 매핑하는 경우, 필요한 파일의 위치와 크기 등을 미리 찾아서 SPT에 저장해둔다.
===>>> 즉 아무 이유 없이 페이지를 만들진 않을 테니, 그 이유와 필요한 데이터에 맞는 메타데이터(위치, 크기 등)를 미리 조사해서 SPT에 담아두고 실제로 사용될 때는 메모리로 “로딩만” 하는 것이다.
SPT의 2가지 목적, 첫 번째 : 페이지 폴트 발생 시
- page fault시 커널은 SPT에서 페이지에 대한 정보를 조회한다. SPT엔 실제 필요한 데이터가 물리 메모리의 어디에 있는지, 어떤 종류의 데이터인지에 대한 메타데이터가 저장되어 있다. 이 정보를 바탕으로 커널은 데이터를 디스크/스왑 영역 등에서 찾아 메모리로 로드한다.
SPT의 2가지 목적, 두 번째 : 프로세스 종료 시
- 프로세스가 사용했던 모든 자원을 회수하기 위해 커널은 SPT를 조회한다. SPT에서 해당 프로세스의 페이지들과 관련된 자원( 메모리 페이지, 파일 매핑, 스왑 슬롯 등)을 확인하고 모두 해제하여 리소스를 정리한다.