Thrashing

Page fault 로 인한 페이지 로딩이 너무 빈번하게 요청되어서 실제 데이터를 가져온 뒤 활용도 못해보고 교체되는 문제

CPU 스케쥴러가 CPU utilization(활용률)을 최대화 시키는 방향으로만 스케쥴링되면 발생하는 문제임. → CPU utilization 이 떨어지면 프로세스를 추가할당

위 한계 구간에서 프로세스가 추가로 할당하면 당연히 Page fault 도 더 많이 발생하고, Thrashing 문제는 더 심해지는 악순환이 발생

따라서 CPU 스케쥴러를 구현할 때 page fault 횟수(frequency)도 고려해서 스케쥴링을 해줘야함

Demand paging 기법은 데이터간의 Locality 를 이용한 기법인데 이 locality 를 유지하기 위한 메모리 크기가 총 메모리 크기보다 커지면 Thrashing 발생

Working-Set

일정 period 동안 프로세스가 동작하는데 필요한 페이지 수

Working-set window = period. window 가 길어지면 Working-set 은 커짐

WSSi(Working set of Process Pi) = 프로세스 i 가 Time window 동안 접근한 Page 의 수 = 프로세스의 Locality 를 평가하는 지표

D = 모든 프로세스의 WSS 의 합

D > m (total memory size) → Thrashing

동일한 프로세스도 언제 측정하냐에 따라 WSS가 다르게 측정됨

WSS 를 지속적으로 Tracking 함으로서 thrashing 의 발생 여부를 검색할 수 있음

그럼 어떻게 WSS 를 Tracking 할 것이냐? Page table에 Reference bit 를 두어 페이지가 참조되었는지 확인하는 방법을 사용

예를 들어 Working set window 가 10000 instruction 이고, Ref bit 가 1개라면 0일 때는 페이지 참조 안됨, 1일때는 페이지 참조 됨을 표현 가능

Ref bit 가 2개라면 5000 으로 time unit 을 쪼개어 두 번 체크한 뒤 더 최근에 사용된 페이지를 찾을 수 있음

Ref bit 수를 늘리거나 체크하는 주기를 줄이는건 물론 OS 의 오버헤드를 늘림

PFF 가 너무 낮으면 Frame 이 과하게 할당된 것이므로 뺏어옴 = 다른 프로세스에 나누어 주려면 해당 시스템이 Global replacement 를 지원해야함

PFF 가 너무 높으면 Frame 이 적게 할당된 것이므로 추가로 할당해줌

Working set 과 Page fault rate 는 연관성이 깊음

프로세스가 처음 실행되면 Demand paging 에 의해 Page fault 가 자주 발생할 수 밖에 없으며, 어느 수준까지 실행된 이후에는 page fault 가 줄어듦