Other Considerations
1) Page Size
가상 메모리 시스템에서 가장 일반적인 페이지 사이즈는 4KB이며, 이보다 크거나 작을 수 있다.
📌 작은 페이지 사이즈의 특징
(1) Internal Fragmentation이 더 작아진다.
페이징 시스템에서도 Internal Fragmentation이 있다. 마지막 페이지는 페이징 프레임에서 남는 공간이 생기기 때문이다. 평균적으로 한 페이지 크기의 절반 정도가 Internal Fragmentation이 된다. (1/2 * PageSize)
(2) 프로그램의 locality를 더 정확히 매칭시킬 수 있다.
Loop을 도는데 페이지 사이즈가 크면 loop이 아닌 부분까지 포함되어서 낭비가 발생한다.
(3) 전체 I/O 시간도 줄어든다.
페이지 사이즈가 작이지니까 그 페이지를 메모리로 로딩시키는 데 드는 시간이 더 적어진다.
(4) I/O 시간이 길어질 수도 있다.
메모리로 들고 오는 시간은 줄 수 있어도 횟수는 더 많아지니까 시간이 길어질 수도 있다.
(5) 페이지 사이즈를 작게 하면 그 만큼 테이블에 들어갈 Entry가 많아지므로 페이지 테이블의 크기가 늘어나는 것은 당연!
즉, 페이지 테이블로 인한 메모리 낭비가 생길 수도 있다.(Table Fragmentation이라고 부르기도 한다.)
(6) page fault가 증가할 수도 있다.
만약 너무 작으면 한 loop에 대해서 페이지가 여러개 있을 수 있고, 따라서 loop을 돌 때마다 page fault가 발생할수도 있다.
➡ 결론
일반적으로는 페이지 사이즈를 작게 하는게 Total I/O 시간을 줄이는 데에 좋다고 검증되었다.
-> 시스템 관리자가 해당 시스템에서 돌아가는 application의 특성을 보고 페이지 사이즈를 잘 결정해야 한다! 대부분은 최근 페이지 사이즈를 크게 하는 쪽으로 가고 있다.
-> 멀티미디어 application이 많아져서 프로그램들이 복잡해지고 크기가 크기 때문이다.
2) Program Restructuring
페이지 크기가 1kb이고 int의 크기가 4byte라고 생각해 보자.
program-1은 column 방향이다.
program-2는 row 방향이고 앞쪽 인덱스를 고정시키고 뒤쪽 인덱스를 변경하는 것이기 때문에 page 0을 전부 다 읽고, 그 다음 페이지를 읽는다.
따라서 program-2는 page fault를 훨씬 줄일 수 있다.
-> 즉 locality를 고려해서 locality를 증진시킬 수 있는 방법으로 코딩을 해야한다.
3) TLB reach
TLB는 Mapping Table을 고속의 기억장치에 일부라도 저장시켜놓고, address mapping의 성능을 높이는 것이다.
TLB에 저장된 Mapping Table의 entry가 8개면(자주 접근되는 것 페이지 8개를 넣어두면) TLB를 통해 접근할 수있는 전체용량은 PageSize 8 = 4kb 8 이다.
TLB reach는 'TLB로 접근가능한 메모리용량'을 의미한다. 즉 엔트리 개수 * 페이지 사이즈이다.
TLB reach를 크게 하려면 엔트리 개수를 늘리거나, 페이지 사이즈를 증가시키는 것이다.
(페이지 사이즈를 단순히 증가시키면 안좋은 영향도 있으므로 multiple page size를 이용하는 경우도 있다.)
어쨌든 TLB Reach가 커진다면, TLB hit ration가 커지기 때문에 좋다.
