컴퓨터에서 병목이 가장 자주 발생하는 곳은 단연 디스크입니다. 하지만 파일 입출력은 시스템에서 끊임없이 반복됩니다. 방금 복사한 파일을 곧바로 에디터로 열거나, 여러 프로세스가 시간차를 두고 동일한 파일에 접근하기도 하죠. 이때 매번 디스크까지 내려간다면 시스템 전체의 성능이 크게 저하될 것입니다.

그래서 리눅스 커널은 RAM 내부에 디스크 데이터의 일부를 보관합니다. 이것이 바로 page cache입니다. 한마디로 요약하면 "디스크에 있는 데이터를 페이지 단위로 RAM에 임시 보관해 두는 커널의 핵심 디스크 캐싱 메커니즘"입니다.

이 장의 큰 흐름은 네 가지입니다. 첫째, 페이지 캐시에 어떤 데이터가 담기는지 살펴봅니다. 둘째, 보관된 페이지들을 어떻게 검색하는지 다루며, 여기서 address_space와 radix tree가 등장합니다. 셋째, 페이지보다 작은 단위인 디스크 블록을 어떻게 페이지 캐시에 편입시키는지 알아보고, 마지막으로 수정된(dirty) 페이지를 언제 어떻게 디스크로 동기화하는지 살펴봅니다. 이 과정에서 pdflush와 sync 계열의 시스템 콜이 연결됩니다.

프로세스가 파일 읽기를 요청할 때, 커널은 곧바로 디스크로 향하지 않습니다. 가장 먼저 페이지 캐시를 확인하여 "이 파일의 해당 위치에 해당하는 페이지가 이미 RAM에 적재되어 있는지"를 살핍니다. 캐시에 존재한다면 디스크 I/O 없이 즉시 반환하고, 없다면 새로운 페이지를 할당한 뒤 디스크에서 데이터를 읽어와 채워 넣습니다.

쓰기 작업의 흐름도 유사하지만 더 흥미롭습니다. 프로세스가 파일에 데이터를 쓸 때, 커널은 먼저 대상 페이지가 캐시에 있는지 확인하고, 없으면 새로 만들어 데이터를 기록합니다. 이때 변경된 내용을 즉시 디스크에 반영하지 않고 잠시 대기합니다. 짧은 시간 안에 같은 페이지가 반복해서 수정될 확률이 높기 때문입니다. 이를 deferred write(지연 쓰기)라고 부릅니다.

페이지 캐시가 다루는 데이터의 범위는 매우 넓습니다. 일반 파일과 디렉터리 데이터는 물론, 블록 디바이스 파일에서 직접 읽은 데이터, 스왑 아웃된 사용자 프로세스 데이터, 그리고 shm과 같은 특수 파일시스템 데이터까지 포함합니다. 여기서 중요한 점은, 페이지 캐시에 적재되는 페이지들은 대개 "특정 파일에 속한 데이터"이며, 해당 파일의 inode가 논리적인 owner(소유자) 역할을 한다는 것입니다.

페이지 캐시에 적재된 페이지를 어떻게 고유하게 식별할 수 있을까요? 페이지 하나가 물리적으로 연속된 디스크 블록들만 담고 있다고 보장할 수는 없습니다. 파일시스템의 논리적 구조를 거치면 파일 내의 오프셋과 실제 디스크 블록의 물리적 배치가 달라질 수 있기 때문입니다.

따라서 커널은 페이지 캐시 내의 페이지를 두 가지 핵심 정보로 식별합니다. 첫째는 owner(대개 inode)이고, 둘째는 index입니다. index는 owner의 주소 공간 안에서 해당 페이지가 몇 번째에 위치하는지를 나타냅니다. 예를 들어, 파일의 0~4095바이트 구간은 index 0, 4096~8191바이트 구간은 index 1이 되는 방식입니다.

이러한 논리적 구조를 담아내는 핵심 자료구조가 바로 address_space입니다. 페이지 디스크립터 내부에는 mapping과 index 필드가 존재하는데, mapping은 이 페이지의 owner를 나타내는 address_space 객체를 가리키고, index는 해당 owner 내에서의 논리적 위치를 의미합니다.

즉, 페이지 캐시는 '디스크의 특정 물리 주소 = 페이지 하나'라는 단순 매핑이 아니라, '어느 owner의 몇 번째 index인가'를 기준으로 하는 논리적 주소 체계를 사용합니다. 이 개념을 명확히 이해해야 뒤이어 등장하는 radix tree의 동작 원리를 쉽게 파악할 수 있습니다.

address_space는 inode 내부에 포함된 구조체로, 해당 inode가 소유한 페이지들을 총괄적으로 관리합니다. 이름은 '주소 공간'이지만, 실제로는 "이 파일에 속한 데이터 페이지들을 어떻게 관리하고 입출력 연산을 수행할 것인가"를 정의하는 커널의 핵심 객체라고 이해하는 것이 좋습니다.

동일한 '페이지 읽기' 작업이라도 대상이 일반 파일인지, 블록 디바이스 파일인지, 혹은 스왑 영역인지에 따라 내부 처리 방식은 완전히 달라집니다. 따라서 커널은 address_space를 통해 각 상황에 맞는 최적의 연산 메서드를 동적으로 선택합니다.

리눅스 환경에서 파일의 크기는 수 기가바이트에서 테라바이트 단위까지 거대해질 수 있습니다. 만약 "이 파일의 100만 번째 페이지가 캐시에 존재하는가?"를 확인하기 위해 선형 리스트를 순회한다면 심각한 성능 저하가 발생할 것입니다. 이를 해결하기 위해 Linux 2.6의 페이지 캐시는 각 address_space마다 radix tree 자료구조를 도입했습니다.

이 트리는 페이지의 index를 일종의 탐색 경로로 해석하여 원하는 페이지 디스크립터에 O(1)에 가까운 속도로 도달하게 해줍니다. 트리의 각 노드는 최대 64개의 포인터를 가질 수 있는데, 64는 2의 6제곱이므로 32비트 index를 6비트 단위로 잘라 각 레벨의 슬롯 번호로 사용하기에 매우 효율적입니다.

결론적으로, 페이지 캐시는 'owner와 index'를 키(key)로 삼아 페이지를 검색하며, 이 검색 과정을 radix tree가 전담함으로써 파일 크기가 아무리 커지더라도 빠르고 확장성 있는 조회가 가능해집니다.

find_get_page()는 주어진 address_space와 offset(index)을 기반으로 페이지 캐시에서 특정 페이지를 검색합니다. 내부적으로 tree_lock을 획득한 뒤 radix tree를 탐색하며, 페이지를 발견하면 다른 프로세스가 임의로 메모리를 해제하지 못하도록 사용 카운터(reference count)를 증가시키고 반환합니다.

새로운 페이지를 캐시에 추가하는 add_to_page_cache()는 트리 삽입 도중 메모리 부족으로 인한 실패를 방지하기 위해 radix_tree_preload()로 필요한 노드를 미리 할당받습니다. 이후 tree_lock을 잡고 radix_tree_insert()를 수행하며, 이때 추가된 페이지의 데이터는 아직 유효하지 않으므로 PG_locked 플래그를 설정하여 접근을 통제합니다.

read_cache_page()는 단순히 페이지의 존재 여부만 확인하는 것이 아닙니다. 페이지가 캐시에 있더라도 PG_uptodate 플래그가 해제되어 있다면(최신 상태가 아니라면), 내부적으로 readpage 콜백을 호출해 디스크로부터 최신 데이터를 읽어와 페이지를 갱신합니다.

시스템에 쌓인 수많은 dirty page를 디스크에 동기화해야 하는 상황을 가정해 봅시다. 특정 inode의 address_space 트리에 수십만 개의 페이지가 연결되어 있고 그중 dirty page는 극소수라면, 이들을 찾기 위해 트리의 모든 leaf 노드를 일일이 순회하는 것은 엄청난 오버헤드를 유발합니다.

이러한 탐색 비용을 최소화하기 위해 radix tree는 tag 메커니즘을 사용합니다. 트리의 각 중간 노드는 자식 포인터마다 tag 공간을 가지고 있으며, dirty tag는 "해당 자식 서브트리 아래에 dirty page가 단 하나라도 존재하는가?"를 나타내는 상태 비트입니다. 만약 특정 노드의 dirty tag가 꺼져 있다면, 그 하위 경로 전체에는 dirty page가 없다는 의미이므로 탐색을 완전히 건너뛸 수 있습니다.

VFS(가상 파일시스템)와 매핑 레이어, 그리고 개별 파일시스템은 데이터를 디스크의 논리적 단위인 '블록(block)' 단위로 다룹니다. 과거의 리눅스 커널은 파일 데이터를 저장하는 page cache와, 메타데이터 등 파일시스템 관리를 위한 블록 데이터를 저장하는 buffer cache를 별도로 운영했습니다.

그러나 Linux 2.4.10 이후부터는 이원화되어 있던 구조를 통합하여, 전통적인 의미의 독립된 buffer cache는 사실상 사라졌습니다. 이제 블록 버퍼들은 buffer page라는 특수한 페이지 내부에 할당되며, 이 buffer page 자체가 page cache 체계 안으로 편입되어 관리됩니다. 즉, 페이지 캐시가 파일 수준의 데이터뿐만 아니라 블록 수준의 데이터까지 모두 아우르게 된 것입니다.

하나의 buffer page 내부에는 여러 개의 블록 버퍼가 포함될 수 있으며, 각각의 블록 버퍼는 자신만의 buffer_head 디스크립터를 가집니다. buffer_head는 커널이 해당 블록의 디스크 주소를 매핑하고 입출력 상태를 추적하기 위해 사용하는 필수적인 메타데이터입니다.

buffer_head의 b_state 필드에는 버퍼의 현재 상황을 나타내는 다양한 상태 플래그가 비트맵 형태로 저장됩니다.

단순한 상태 표기 외에도 b_count(사용 카운터)의 역할이 매우 중요합니다. 커널의 특정 루틴이 블록 버퍼를 다루고자 할 때는 반드시 카운터를 증가시켜야 하며, 작업이 끝나면 감소시켜야 합니다. 카운터가 0으로 떨어진 버퍼만이 메모리 회수(Reclaim)의 대상이 될 수 있습니다. "누군가 사용 중인 데이터는 절대 임의로 해제하지 않는다"는 커널의 기본적인 동기화 철학입니다.

버퍼 사용을 완료했을 때는 주로 __brelse()나 __bforget() 함수를 호출합니다. 두 함수 모두 사용 카운터를 감소시키는 역할을 하지만, __bforget()의 동작이 훨씬 강력합니다. 간접 블록 리스트(indirect block list)에서 버퍼를 완전히 제거할 뿐만 아니라, dirty 상태 플래그까지 초기화하여 아직 디스크에 반영되지 않은 변경 사항을 커널이 '잊어버리게' 만듭니다.

Buffer page는 주로 두 가지 상황에서 생성됩니다. 첫째, 파일 데이터를 담은 페이지를 구성하는 실제 디스크 블록들이 물리적으로 연속되어 있지 않은 경우입니다. 둘째, 슈퍼블록(superblock)이나 inode 블록처럼 논리적인 파일 구조를 우회하여 단일 디스크 블록에 직접 접근해야 할 때입니다.

블록 디바이스용 buffer page를 새롭게 할당해야 할 때, 커널은 grow_buffers() 함수를 호출합니다. 이 함수는 대상 디바이스의 디스크립터(bdev), 논리 블록 번호(block), 그리고 블록 크기(size)를 인자로 받아 내부 구조를 세팅합니다.

사용이 끝난 buffer page를 해제하는 과정은 생성보다 훨씬 까다롭습니다. try_to_release_page()가 호출되더라도, 페이지 자체가 PG_writeback 상태이거나 포함된 buffer_head 중 단 하나라도 BH_Dirty 또는 BH_Lock 상태를 띄고 있다면 메모리를 즉각 반환할 수 없습니다. 모든 조건이 안전하다고 판단될 때만 간접 버퍼 리스트에서 제거하고, PG_private 플래그를 지운 뒤 소속된 buffer_head 객체들을 최종적으로 메모리에서 해제합니다.

커널이 "특정 블록 하나"를 단독으로 읽거나 쓰고 싶을 때 거치는 탐색 경로입니다. 예를 들어 파일시스템 마운트 과정에서 슈퍼블록을 읽어야 한다면, 커널은 무작정 디스크로 I/O 요청을 보내지 않고 해당 블록 버퍼가 이미 page cache 내부에 존재하는지 먼저 확인합니다.

탐색 성능을 극대화하기 위해, 시스템은 각 CPU 코어마다 bh_lrus라는 작고 빠른 LRU(Least Recently Used) 블록 캐시 배열을 운용합니다. 여기에는 가장 최근에 접근한 8개의 buffer_head 포인터가 보관됩니다. __find_get_block() 함수는 전역 page cache를 뒤지기 전에 이 CPU 로컬 캐시를 먼저 확인하며, b_bdev, b_blocknr, b_size가 정확히 일치하는 객체가 존재하면 이를 배열의 선두로 끌어올린 뒤 b_count를 증가시켜 즉시 반환합니다.

메모리 상의 buffer_head 객체가 실제 디스크 I/O 요청으로 변환되어 하위 계층으로 내려가는 과정입니다. 핵심 함수인 submit_bh()는 전송 방향(READ 또는 WRITE)과 타깃 buffer_head 포인터를 인자로 받습니다. 이 함수가 호출되는 시점에는 이미 b_bdev, b_blocknr, b_size 등의 논리 블록 맵핑 정보가 완벽히 세팅되어 있어야 합니다.

여러 개의 블록을 일괄 처리해야 할 때는 통상 ll_rw_block()이 활약합니다. 이 함수는 배열로 전달된 각 buffer_head에 대해 BH_Lock 플래그를 test-and-set 방식으로 점검하여, 이미 I/O가 진행 중(locked)인 블록은 안전하게 건너뜁니다. 쓰기 요청 시에는 BH_Dirty 여부를, 읽기 요청 시에는 BH_Uptodate 여부를 추가로 검사하여, 실제 물리적인 전송이 불가피한 버퍼들만 선별해 submit_bh()로 넘깁니다.

사용자 프로세스가 파일의 내용을 수정하면 해당 메모리 페이지는 'dirty' 상태가 되며, PG_dirty 플래그가 켜집니다. 커널은 이 변경 사항을 즉각 디스크로 내려쓰지 않고 메모리에 머무르게 하는 '지연 쓰기(Deferred Write)' 전략을 취합니다. 한 페이지의 특정 영역이 짧은 시간 내에 수십 번 변경되더라도, 최종적으로 디스크에는 단 한 번의 I/O만 발생하게 만들어 시스템의 전반적인 처리량을 비약적으로 상승시키기 위함입니다.

하지만 지연 쓰기 전략을 무한정 유지할 수는 없습니다. 갑작스러운 전원 차단이나 커널 패닉이 발생하면 RAM에만 머물러 있던 dirty 데이터는 영구적으로 소실되며, 쓰기 작업을 계속 미루기만 하면 시스템의 가용 메모리가 순식간에 고갈될 것이기 때문입니다. 따라서 커널은 성능과 안정성 사이의 아슬아슬한 줄타기를 하며, 특정 조건이 만족될 때마다 dirty page들을 디스크로 조심스럽게 방출(flush)합니다.

과거 리눅스의 bdflush와 kupdate 데몬이 하던 역할은 Linux 2.6에 이르러 pdflush라는 유연한 커널 스레드 풀(Thread Pool)로 대체되었습니다. pdflush는 특정 콜백 함수와 인자를 주입받아 다양한 조건의 flush 작업을 비동기적으로 수행하며, 시스템의 I/O 부하에 따라 스레드의 개수를 최소 2개에서 최대 8개까지 동적으로 유연하게 조절합니다.

수면 상태의 pdflush 스레드를 깨워 작업을 지시할 때는 wakeup_bdflush()를 호출하며, 이때 background_writeout() 콜백이 함께 전달됩니다. 인자로 넘기는 숫자는 한 번에 디스크로 밀어낼 dirty page의 목표 개수이며, 만약 0이 전달되면 시스템 내의 모든 dirty page를 긁어모아 쓰라는 강력한 전체 flush 지시가 됩니다.

background_writeout() 함수의 심장부에는 writeback_control 구조체가 자리 잡고 있습니다. 이 객체는 "어떤 데이터를, 얼마나, 어떤 방식으로 디스크에 내보낼 것인가"에 대한 상세한 작전 명령서인 동시에, "현재까지 얼마나 많은 페이지를 성공적으로 처리했는가"를 실시간으로 추적하는 상태 보고서의 역할까지 겸비합니다.

세부적인 쓰기 과정은 writeback_inodes()가 시스템 내의 슈퍼블록(superblock) 목록을 순회하는 것으로 본격화됩니다. 각 슈퍼블록이 내부적으로 유지하고 있는 s_dirty(더티 상태의 inode 리스트)에서 당장 처리할 대상들을 선별하여 s_io(I/O 대기 리스트)로 옮긴 후, sync_sb_inodes()를 통해 하나씩 본격적인 I/O 파이프라인에 태웁니다.

만약 특정 메모리 페이지가 메모리 회수 압박도 받지 않고 명시적인 동기화 요청도 없이 캐시에 계속 방치된다면 어떻게 될까요? 커널은 특정 데이터가 영구적으로 디스크에 쓰이지 못하는 기아(Starvation) 상태를 원천적으로 차단해야 합니다. 이 최후의 방어선 역할은 주기적인 커널 타이머 wb_timer와 wb_kupdate() 콜백이 담당합니다.

지금까지 살펴본 바와 같이, 리눅스의 페이지 캐시는 단순히 "디스크에서 읽어온 데이터를 쌓아두는 RAM 조각"을 아득히 뛰어넘는 정교한 아키텍처입니다. 데이터를 owner와 index의 조합으로 논리적으로 추상화하고, address_space라는 매니저로 통제하며, radix tree로 폭발적인 검색 성능을 확보합니다. 더 나아가 트리 노드에 tag를 달아 상태를 맵핑하고, buffer_head를 품어 블록 디바이스와의 하위 호환성을 완벽히 유지하며, pdflush 메커니즘을 통해 시스템 성능과 무결성의 황금비를 찾아내는 리눅스 I/O 서브시스템의 진정한 심장부이자 교차로입니다.