리눅스 페이지 캐시 정책

운영체제에서 페이지 캐시는 스토리지 접근을 줄여 애플리케이션 성능을 최적화하는 것에 핵심적인 기여를 한다. 

 

그동안 리눅스 운영체제는 페이지 캐시에 one size fits all 방식이라는 고정된 싱글 정책을 사용했다. 

기존 리눅스 커널의 기본 evict 정책은 active list와 inactive list라는 FIFO로 동작하는 두 개의 리스트를 사용하는 LRU 방식이었다. 

 

각각의 리스트는 control group인 리눅스의 cgroup마다 분할되어 관리된다. 프로세스 그룹마다 리소스 사용을 isolation하여 cgroup마다 자체적인 page cache list set을 가지게 된다. 

 

스토리지에서 folio 페이지가 처음 로드되면 inactive list의 tail로 admission된다. 

(리눅스는 페이지 구조체 개념을 싱글 페이지 또는 연속된 피지컬 페이지 묶음 compound page의 헤드 페이지를 의미하는 folio로 전환하고 있다. )

해당 페이지에 다시 접근하게 되면 active list로 promote 되어 자주 사용하는 페이지로 유지된다. 

메모리가 더 필요해지면 inactive list에서 head에 위치한 페이지부터 eviction하게 되고 

리스트의 밸런스를 조정하거나 메모리를 줄이고자 할 때 active list의 head에 있는 페이지부터 inactive list의 tail로 demotion 될 후보가 된다.

 

eviction을 inactive list의 head부터 수행하는 이유는 재사용 가능성이 낮은 페이지가 위주로 모여있는 리스트에서 가장 오래된 페이지이기 때문이다. 다만 단순하게 head 기반으로 결정되는 것은 아니고 aging, referenced bit, pressure 등을 기반으로 후보 중 결정된다. 

 

이 동작 플로우에서 inactive list는 preliminary filter 역할을 수행해서 짧게 사용되는 페이지들이 active list를 오염시키는 것을 방지한다. 다만 active list의 페이지가 inactive list로 demotion 되면 다시 promotion 될 수도 있지만 대부분 demotion의 시점이 aggressive 하기 때문에 실제로는 다시 promotion될 기회를 얻기 어렵다. 

 

리눅스에서 모든 시나리오에 적합하도록 싱글 폴리시를 채택하고 있기 때문에 많은 워크로드에서 성능 저하를 일으킬 수 있다. 특히 파일 검색 작업처럼 대규모 스캔 위주의 워크로드는 방대한 양의 데이터를 순차적으로 읽고 한 번 읽고 나면 대다수의 데이터에 재접근하지 않기 때문에 캐시 공간만 차지하게 된다. 즉 스캔 페이지가 캐시를 오염시킨다고 볼 수 있다. 다만 cold scan data가 recently accessed 힌트를 주기 때문에 false locality 문제가 일어날 수도 있다. (한 번 보고 다시 안 보는 cold 데이터를 LRU는 가장 최근에 읽힌 데이터가 중요하다, 재접근 가능성이 높다고 판단하는데 스캔 워크로드는 cold 데이터를 시퀀셜하게 계속 읽기 때문에 모든 cold 데이터가 최근에 접근된 것처럼 보인다. 

 

스캔 페이지가 더 최근에 접근되었기 때문에 중요한 frequently accessed data = 재사용 가치가 높은 핫셋 페이지가 active list에서 demotion되거나 inactive list에서 evict될 확률 높고 디스크에서 데이터를 다시 로드해야하므로 thrashing 을 경험하게 된다.  (thrashing = 페이지가 evict된 후 바로 다시 reload되는 현상)

 

thrashing을 완화하기 위해 페이지 캐시는 shadow entry들을 추적하게 된다. 페이지가 evict된 후에도 메타 데이터를 유지해서 eviction과 새 request 사이 각 지점 사이 거리를 의미하는 refault distance 를 계산하고 최근에 evict된 페이지가 다시 insert된다면 이 페이지를 inactive list가 아닌 바로 active list로 insert될 수 있게 커널이 결정해줄 수도 있다. 

 

즉, 모든 워크로드를 개선하는 단 하나의 one size fits all 정책은 없으며 성능을 최대화하기 위해서는 애플리케이션 고유 특성에 맞게 페이지 캐시 정책을 커스터마이즈하고  다양한 정책을 실험하는 것이 필수적이다. 

 

또한 페이지 캐시 정책 자체가 커널의 메모리 관리 코드, 파일시스템 코드와 크게 연관되어 있기 때문에 변경을 위해서는 많은 커널 지식이 필요하고 안정성을 해칠 위험성 또한 크다.  

 

그래서 애플리케이션이 자체적으로 유저 스페이스 캐시를 구현하여 사용하지만 운영체제가 관리하는 페이지 캐시와 데이터가 중복되어서 메모리를 낭비하고 시스템 전체의 메모리 상황에 따라 동적으로 캐시 조절이 어렵고 프로세스끼리 캐시를 공유하기 어렵다는 새로운 단점이 발생한다.