둘을 분리해서 얻는 것은 매핑의 자유입니다. 프로세스마다 page table이 따로 있으므로 서로 다른 프로세스의 같은 가상 주소가 다른 frame을 가리킬 수 있고, 반대로 서로 다른 page가 같은 frame을 가리키게 할 수도 있습니다. 공유 라이브러리가 물리 메모리에 한 벌만 올라가는 것, fork 직후 부모와 자식이 메모리를 복사 없이 공유하는 copy-on-write가 모두 후자의 응용입니다.

또한 프로그램은 자기 page들이 연속된 주소 공간이라고 보지만, 실제 frame은 물리 메모리 어디에 있어도 됩니다. "연속으로 보이는 것"과 "실제 배치"를 분리한 덕에, 물리 메모리에 연속된 큰 빈 공간이 없어도 큰 할당이 가능합니다.

demand paging은 "실제로 접근하기 전까지는 올리지 않는다"는 게으른 적재 전략입니다. 실행 파일을 통째로 메모리에 올리는 대신 page table에 매핑만 만들어 두면, 프로그램 시작이 빨라지고 실제로 쓰이지 않는 코드(예외 처리 경로, 안 쓰는 기능)는 영영 메모리를 차지하지 않습니다. page fault는 이 전략에서 "이제 진짜 필요해졌다"는 신호로 쓰이는 정상 메커니즘입니다.

fault의 비용 차이로 minor fault와 major fault를 구분합니다. minor fault는 디스크 I/O 없이 처리되는 경우로, 데이터가 이미 메모리(page cache)에 있어 매핑만 만들면 됩니다. major fault는 디스크에서 실제로 읽어야 하는 경우로 수 ms가 걸릴 수 있습니다. 성능 분석에서 문제가 되는 것은 대부분 major fault의 빈도입니다.

관계를 정리하면 page fault는 입구이고 segmentation fault는 여러 출구 중 하나입니다. MMU가 변환에 실패하면 일단 page fault가 발생하고, OS가 원인을 판별합니다. 유효한 주소인데 아직 안 올라온 것이면 적재 후 재개하고, copy-on-write page에 쓰기가 들어온 것이면 복사본을 만들어 재개합니다. 둘 다 프로그램은 fault가 있었는지도 모릅니다.

반면 그 주소가 프로세스에 할당된 적이 없거나(해제된 pointer, NULL) 권한이 없는 접근(읽기 전용 영역에 쓰기)이면, OS는 복구할 방법이 없으므로 프로세스에 SIGSEGV 신호를 보냅니다. 이것이 개발자가 보는 segmentation fault입니다. 즉 같은 하드웨어 메커니즘이 정상 동작과 오류 통보에 함께 쓰이고, 갈림길은 OS의 판단입니다.

정확한 LRU는 모든 메모리 접근마다 순서 기록을 갱신해야 해서 OS 수준에서는 비용이 너무 큽니다. 그래서 실제로는 근사 알고리즘을 씁니다. 대표적인 clock 알고리즘은 page마다 참조 비트를 두고, 하드웨어가 접근 시 비트를 켜면 OS가 원형으로 돌며 비트가 켜진 page는 끄고 넘어가고 꺼진 page를 교체 대상으로 고릅니다. "최근에 한 번이라도 쓰였는가"만 보는 값싼 LRU 근사입니다.

내보낼 page의 상태도 비용을 좌우합니다. 적재 후 수정되지 않은 page는 디스크의 원본과 같으므로 그냥 버리면 되지만, 수정된 dirty page는 버리기 전에 디스크에 써야 해서 두 배로 비쌉니다. 그래서 OS는 dirty 비트를 추적하고, 여유 있을 때 미리 디스크에 써 두어(writeback) 교체 시점의 비용을 줄입니다.

페이징은 내부 단편화가 발생합니다. 1바이트짜리 데이터도 페이지(4KB) 하나를 통째로 차지해 나머지 4095바이트가 낭비됩니다.

세그멘테이션은 가변 크기로 할당하므로 내부 낭비는 없지만, 할당과 해제가 반복되면 빈 공간이 조각나는 외부 단편화가 생깁니다. 빈 공간이 2+2바이트로 나뉜 상태에서 4바이트 연속 할당 요청이 오면 실패합니다.

현대 OS는 페이징을 기본으로 쓰기 때문에 외부 단편화는 거의 발생하지 않습니다. 페이지 크기가 고정되어 있어 빈 frame을 어느 page에도 재사용할 수 있기 때문입니다.

thrashing의 악순환 구조를 보면, 어떤 프로세스가 방금 내보낸 page를 곧 다시 필요로 하면 다시 fault가 나고, 그 page를 올리려고 또 다른 필요한 page를 내보냅니다. 모든 프로세스가 이 상태에 빠지면 CPU는 대부분의 시간을 디스크 I/O 대기에 쓰므로, 겉보기에는 CPU 사용률이 낮은데 시스템은 멈춘 것처럼 느려집니다.

working set은 "프로세스가 최근 일정 구간 동안 실제로 사용한 page 집합"으로, thrashing의 판별 기준이 됩니다. 실행 중인 모든 프로세스의 working set 합이 물리 메모리를 넘으면 thrashing이 시작됩니다. 고전적인 해법은 동시에 실행하는 프로세스 수를 줄여 남은 프로세스의 working set이라도 온전히 담는 것이고, 현대 시스템에서는 메모리 압박이 한계에 달하면 Linux의 OOM killer처럼 프로세스를 강제 종료해 시스템 전체가 멈추는 것을 막습니다.