운영체제에게 메모리 할당만큼이나 중요한 것은, 할당된 메모리를 다시 안전하게 '회수'하는 기술입니다.

커널은 시스템이 요구하는 순간마다 물리 메모리인 페이지 프레임을 할당합니다. 동시에 커널은 남는 RAM 공간을 결코 낭비하지 않습니다. 파일 데이터, 디스크 블록, inode, dentry 등 빈번하게 접근하는 정보들을 캐시(Cache) 영역에 보관하여 시스템 성능을 극대화합니다. 그러나 이러한 캐시는 스스로 "이제 사용하지 않으니 메모리를 반환하겠다"고 나서지 않습니다. 시간이 흐르면 RAM은 점차 프로세스가 할당받은 페이지와 커널의 캐시 데이터로 가득 차게 됩니다.

바로 이 한계 상황에서 개입하는 것이 PFRA, 즉 Page Frame Reclaiming Algorithm입니다. 이번 장을 관통하는 세 가지 핵심 질문은 다음과 같습니다. 무엇을 회수할 것인가? 회수 과정에서 시스템의 어떤 부분을 수정해야 하는가? 그리고 회수된 페이지가 훗날 다시 필요해질 때 어떻게 원상 복구할 것인가?

이 장은 크게 네 가지 주제로 전개됩니다. 첫째, PFRA의 근본적인 목적과 회수 대상이 되는 페이지의 분류 체계를 살펴봅니다. 둘째, 여러 프로세스가 공유하는 페이지를 안전하게 회수하기 위한 핵심 기술인 reverse mapping을 다룹니다. 셋째, 실제 Linux 환경에서 PFRA가 LRU 리스트와 각종 shrink 함수, kswapd 데몬, 그리고 최후의 보루인 OOM killer를 통해 어떻게 유기적으로 동작하는지 추적합니다. 마지막으로, 원본 파일이 없는 anonymous page를 디스크에 보관하는 swapping 메커니즘을 학습합니다.

커널이 메모리 부족을 겪는다고 해서 아무 페이지나 무작정 회수해도 될까요? 당연히 그렇지 않습니다. 어떤 페이지는 건드리는 순간 시스템 전체가 붕괴할 수 있고, 어떤 페이지는 내용이 유실되지 않도록 사전에 디스크에 기록(writeback)해야 하며, 또 어떤 페이지는 쿨하게 즉시 버려도 무방합니다. 따라서 PFRA는 모든 페이지를 철저하게 네 가지 범주로 분류하여 관리합니다.

분류 시 또 하나 간과해선 안 될 중요한 기준은 해당 페이지가 shared(공유됨) 상태인지, 아니면 non-shared(독점 사용됨) 상태인지의 여부입니다. fork() 시스템 콜 이후 부모와 자식 프로세스가 Copy-On-Write(COW) 방식으로 페이지를 공유하거나, 여러 프로세스가 mmap을 통해 동일한 파일을 메모리에 매핑할 경우, 단일 물리 페이지 프레임을 여러 프로세스가 동시에 가리키게 됩니다. 이러한 공유 페이지를 안전하게 회수하려면, 해당 물리 프레임을 가리키는 '모든' Page Table Entry(PTE)를 일일이 찾아내어 연결을 끊어야 합니다. 이 복잡한 과정을 해결하기 위해 뒤이어 등장하는 개념이 바로 reverse mapping입니다.

수천, 수만 개의 회수 가능한 페이지가 존재할 때, 커널은 과연 어떤 녀석부터 타겟으로 삼아야 할까요? 안타깝게도 PFRA의 설계에 있어 수학적으로 증명된 '완벽한 정답'은 존재하지 않습니다. 대신 철저하게 시스템 성능과 안정성을 고려한 실전적 경험칙(heuristic)들의 정교한 조합으로 이루어집니다.

가정해 봅시다. 커널이 절박하게 물리 메모리를 확보해야 해서 특정 page frame 하나를 타겟으로 삼았습니다. 과연 이 물리 프레임을 현재 '어느 프로세스'의 '어떤 page table entry(PTE)'들이 가리키고 있을까요? 메모리를 탐색하는 일반적인 방향은 가상 주소(Virtual Address)에서 출발하여 Page Table을 거쳐 물리적인 Page Frame에 도달하는 정방향입니다. 하지만 PFRA에게 당장 필요한 것은 정확히 그 반대의 시야입니다. 주어진 물리 페이지 프레임에서 출발하여 역으로 그것을 참조하는 모든 사용자 PTE들을 색출해 내는 기술, 이것이 바로 Reverse Mapping(역방향 매핑)입니다.

실제 메모리 매핑 해제의 관문 역할을 하는 함수는 try_to_unmap()입니다. 이 함수는 앞서 언급한 mapping 필드의 최하위 비트를 검사하여, 페이지의 태생이 anonymous인지 file-mapped인지 판별합니다. 그 후 각자의 특성에 맞게 try_to_unmap_anon() 또는 try_to_unmap_file()로 제어권을 넘깁니다. 최종적으로 해당 페이지가 더 이상 어떤 프로세스에도 매핑되지 않은 상태가 되면, 비로소 회수 작전이 성공한 것으로 간주합니다. 포인터 주소가 메모리에 정렬(alignment)되는 특성을 십분 활용해 빈 하위 비트를 상태 플래그로 전용하는 것은, 메모리 바이트 하나조차 아끼려는 시스템 프로그래밍 특유의 치열한 최적화 기법입니다.

Anonymous page는 말 그대로 디스크 상의 '이름 있는 파일'과 아무런 연결 고리가 없는 순수 메모리 조각입니다. 개발자가 동적으로 할당받는 프로세스의 Heap이나, 함수 호출 시 생성되는 Stack 영역이 대표적입니다. fork() 시스템 콜이 호출되면 부모와 자식 프로세스는 Copy-On-Write(COW)라는 효율적인 방식으로 같은 물리 페이지 프레임을 당분간 사이좋게 공유하게 됩니다. Linux 커널은 이렇게 얽히고설킨 익명 메모리 영역(Anonymous Region)들을 체계적으로 추적하기 위해 anon_vma라는 특별한 연결 고리를 사용합니다.

Mapped page는 디스크 상의 특정 파일 블록과 운명 공동체로 묶인 페이지입니다. 가장 대표적인 예로 C 표준 라이브러리(libc) 같은 공유 객체를 들 수 있는데, 시스템 상의 거의 모든 활성 프로세스가 이를 자신의 주소 공간에 매핑하여 사용합니다. 만약 이런 초거대 공유 페이지를 회수하기 위해 커널 내의 모든 vm_area_struct를 일일이 순차 탐색(linear scan)한다면, 시스템 성능은 끔찍하게 저하될 것입니다. 이를 타개하기 위해 Linux 2.6은 mapped page 관리에 특화된 Priority Search Tree (PST)라는 훌륭한 자료구조를 도입했습니다.

커널의 관점에서, 특정 파일과 연결된 각각의 메모리 영역(memory region)은 그 파일 내에서의 시작 페이지 인덱스와 끝 페이지 인덱스를 양 끝점으로 하는 하나의 연속된 구간(interval)으로 추상화할 수 있습니다. PST는 바로 이 구간 데이터들을 최적화하여 구성한 트리로, "특정 파일의 N번째 페이지 인덱스를 포함하고 있는 모든 메모리 영역들을 즉시 내놓아라!"라는 쿼리에 극적으로 빠르게 응답하도록 설계되었습니다. 각 파일은 자신만의 고유한 PST를 보유하며, 트리의 최상위 루트 노드는 해당 파일의 inode 구조체 내부에 위치한 address_space 객체의 i_mmap 필드에 고이 모셔져 있습니다.

PFRA 시스템이 가동되는 '방아쇠(trigger)'는 크게 세 가지 경로로 나뉩니다. 첫 번째이자 가장 급박한 입구는 Low on memory reclaiming (메모리 고갈 시 회수)입니다. 시스템이 메모리를 요청했는데 더 이상 줄 공간이 없을 때 비상사태처럼 발동합니다. 버퍼 페이지를 생성하지 못하거나, buddy system이 요구된 연속된 페이지 프레임을 토해내지 못하면 try_to_free_pages()와 같은 핵심 구원 투수들이 즉각 마운드에 오릅니다. 두 번째 입구는 Hibernation reclaiming (동면을 위한 회수)입니다. 시스템이 suspend-to-disk(최대 절전 모드) 상태로 안전하게 전환되려면, 현재 RAM의 상태를 덤프하기 전에 메모리를 최대한 깔끔하게 압축하고 정리해 두어야 합니다. 세 번째 입구는 평상시 건강을 유지하는 Periodic reclaiming (주기적 회수)으로, 백그라운드에서 묵묵히 일하는 kswapd 커널 스레드가 그 주인공입니다.

응급실의 헤드 닥터 격인 try_to_free_pages()는 메모리 부족 사태를 해결하기 위한 최전선 지휘관입니다. 이 함수는 shrink_caches와 shrink_slab 함수를 반복적으로 호출하며, 마치 나사를 조이듯 점진적으로 회수 압박의 강도를 높여갑니다. 이 강도를 조절하는 변수가 바로 priority(우선순위)인데, 가장 여유로운 12에서 시작해 가장 극단적인 0까지 점차 카운트다운 됩니다. 우선순위 숫자가 낮아질수록 상황이 절박함을 의미하며, 스캔하고 검사하는 페이지의 범위도 폭발적으로 늘어납니다. 이들의 일차적 목표는 시스템이 숨을 쉴 수 있는 최소한의 단위인 32개의 페이지 프레임을 긴급 수혈하는 것입니다. 만약 강도를 0까지 낮추며 무려 13번이나 쥐어짜냈음에도 불구하고 이 목표 달성에 실패한다면, 커널은 시스템 전체의 마비를 막기 위해 최후의 사형 집행인인 OOM(Out-Of-Memory) killer를 소환할 수밖에 없습니다.

Linux 커널은 사용자 프로세스의 주소 공간에 매핑된 페이지들과 파일 시스템의 page cache에 속한 페이지들을 효율적으로 통제하기 위해, 전체 페이지들을 거대한 두 개의 리스트로 나누어 관리합니다. 하나는 최근까지 활발하게 참조된, 아직 따뜻한 온기가 남아있는 페이지들이 모인 Active List (활성 리스트)입니다. 다른 하나는 한동안 누구의 관심도 받지 못해 차갑게 식어버린, 회수 1순위 후보군이 모인 Inactive List (비활성 리스트)입니다. 메모리가 부족해질 때 PFRA가 매처럼 눈을 번뜩이며 주로 덮치는 사냥터가 바로 이 inactive list입니다.

그렇다면 inactive list의 그늘에 있던 페이지는 어떤 과정을 거쳐 active list로 화려하게 승격될까요? 커널 내부에서 "이 페이지가 방금 참조되었다!"라는 확신이 들 때 호출되는 함수가 mark_page_accessed()입니다. 하지만 커널은 성급하지 않습니다. 단 한 번 접근되었다고 해서 섣불리 페이지를 active list 최상단으로 끌어올리지 않습니다. 여기서 PG_referenced 플래그가 일종의 '진동 댐퍼(완충 장치)' 역할을 수행합니다. 완전히 잊혀졌던 페이지(PG_referenced=0)에 첫 번째 접근(access)이 발생하면, 커널은 페이지를 당장 승격시키는 대신 '관심 대상'이라는 의미로 플래그만 1로 켜둡니다. 그리고 그 플래그가 켜진 상태에서 짧은 시간 안에 두 번째 접근이 발생했을 때 비로소 "이 페이지는 확실히 다시 쓰이고 있다"고 판단하여 active list로 당당히 올려보냅니다.

물론 active list로 올라갔다고 해서 영원한 안락함이 보장되는 것은 아닙니다. 시스템의 메모리 상황과 페이지의 접근 패턴에 따라 신분은 언제든 강등될 수 있습니다. 평소 백그라운드에서 page_referenced()와 refill_inactive_zone() 메커니즘이 active list를 끊임없이 훑어보며, 한동안 접근된 흔적이 없는 게으른 페이지들을 가차 없이 inactive list로 끌어내려 다음 회수의 희생양으로 준비시킵니다.

시스템 메모리가 부족해진다고 해서 커널이 곧바로 사용자의 프로세스 페이지를 강제로 뜯어내 스왑 영역으로 쫓아낼까요? 그렇지 않습니다. 가급적 사용자 경험에 타격을 주는 일은 피하려 노력합니다. refill_inactive_zone()은 활성 리스트(active list)에 있는 페이지들을 골라 비활성 리스트(inactive list)로 강등시키는 심판관 역할을 합니다. 이 심판관이 "사용자 프로세스의 페이지까지 자비 없이 끌어내릴 것인가?"를 결정하는 공격성의 핵심 지표가 바로 Swap Tendency(스왑 경향성)입니다.

위 공식의 작동 원리는 명확합니다. 세 항목을 더해 산출된 swap tendency 수치가 '100'이라는 마지노선을 넘어서는 순간, PFRA는 눈빛을 바꾸어 유저 모드의 매핑된 페이지들까지 가차 없이 inactive list로 강등시키며 스왑 아웃의 제물로 삼기 시작합니다. 만약 관리자가 swappiness 값을 0으로 극단적으로 낮춰둔다면, distress 값이 미친 듯이 치솟는 시스템 붕괴 직전의 상황이 오기 전까지는 유저 프로세스의 메모리에는 손대지 않으려 버틸 것입니다. 반대로 100으로 올려둔다면, 커널은 평상시에도 유저 페이지 캐시 페이지를 차별 없이 적극적으로 회수 대상 테이블에 올리게 됩니다.

refill_inactive_zone() 함수의 동선 또한 흥미롭습니다. 이 함수는 언제나 active list의 꼬리(tail), 즉 리스트 내에서도 가장 오랫동안 관심에서 멀어져 있던 녀석들부터 끄집어내어 심문을 시작합니다. 만약 최근에 다시 참조된 흔적이 명백하거나, 방금 계산한 swap tendency 수치가 낮아 유저 페이지를 굳이 건드릴 명분이 없거나, 심지어 익명(anonymous) 페이지인데 스왑 공간조차 마련되지 않은 불쌍한 처지라면 다시 active list의 머리(head) 쪽으로 온정 있게 돌려보냅니다. 이 모든 가혹한 심사를 뚫고 강등 판정을 받은 페이지들만이 비로소 inactive list의 심연으로 떨어지게 됩니다.

메모리 할당 요청이 실패했을 때, 커널 내부에서는 생존을 위한 어떤 다급한 연쇄 반응이 일어날까요? 가장 먼저 free_more_memory()가 호출되어 백그라운드에서 잠자던 pdflush 스레드를 다급히 깨웁니다. 이들에게 메모리에 쌓인 더티(dirty) 데이터들을 서둘러 디스크로 쏟아내라고 독촉하기 위함입니다. 그 직후, 커널은 각 메모리 노드의 부족 상태에 놓인 구역(low memory zone)들을 타겟으로 삼아 구원 투수인 try_to_free_pages() 함수를 본격적으로 투입합니다. 이 함수는 앞서 언급한 우선순위(priority) 레벨을 12에서 0까지 단계적으로 조이면서, 내부적으로 shrink_caches()와 shrink_slab()이라는 양대 회수 엔진을 미친 듯이 회전시킵니다.

priority 수치가 낮아져 상황이 점차 절박해질수록, 알고리즘은 active 및 inactive 리스트에서 스캔하는 페이지의 '비율'을 무자비하게 끌어올립니다. 여기서 커널의 꼼꼼함이 빛을 발하는데, 이번 회수 턴에서 스캔해야 할 할당량이 너무 적어(예: 32개 미만) 무시하고 넘어간 스캔 분량은 nr_scan_active와 nr_scan_inactive 변수에 조용히 누적(마일리지처럼 적립)해 둡니다. 그리고 다음번 호출 시 이 빚을 한꺼번에 청구하여, 단 하나의 잉여 페이지도 알고리즘의 그물망을 빠져나가지 못하도록 철저히 계산합니다.

모든 지시를 거쳐 도달한 shrink_list()는 PFRA 알고리즘의 진정한 핵심 엔진이자, 페이지들의 운명이 결정되는 최후의 심문소입니다. 건네받은 page_list 묶음을 펼치고 페이지 하나하나를 현미경 보듯 깐깐하게 검열하며 회수를 시도합니다. 이 치열한 심문의 결과는 보통 세 갈래로 나뉩니다. 첫째, 모든 결점을 털어내고 완벽히 '자유의 몸'이 되어 buddy system(가용 메모리 풀)으로 환원되거나. 둘째, 당장은 조금 얽힌 실타래가 남아있지만 곧 풀릴 듯하여 inactive 리스트에 조금 더 보류되거나. 셋째, 누군가 최근에 다시 접근했거나 처리하기 너무 까다로워 다시 영광의 active 리스트로 복권되는 것입니다.

커널의 PFRA가 먹잇감을 찾는 곳이 오로지 사용자 페이지와 파일이 얽힌 LRU 리스트뿐일까요? 아닙니다. 보이지 않는 곳에서 메모리를 야금야금 포식하고 있는 거대한 그림자들이 또 있습니다. 바로 파일 경로를 캐싱하는 dentry cache, 파일 메타데이터를 품은 inode cache, 디스크 쿼터(quota) 캐시 등 각종 파일 시스템 부속물들입니다. 이 녀석들이 무분별하게 비대해지는 것을 막기 위해, 어떤 특수 목적 캐시가 PFRA의 통제를 받고 싶다면 시스템 부팅이나 초기화 시점에 스스로 Shrinker function (수축 함수)을 등록하는 예의를 갖춰야 합니다. set_shrinker() 인터페이스를 통해 등록을 마치면, 이 함수 포인터들은 커널 전역의 shrinker_list라는 체인에 주렁주렁 매달리게 됩니다.

메모리가 부족해질 때 호출되는 shrink_slab()이라는 함수는 이름 때문에 종종 "Slab Allocator(슬랩 할당자) 전용 청소기"로 뼈아픈 오해를 받곤 합니다. 그러나 실상 이 함수의 진정한 정체는 등록된 수많은 'shrinkable disk cache'들의 shrinker 함수들을 순차적으로 깨워 실행시키는 무자비한 집행관입니다. 이 함수는 임의로 캐시를 날려버리지 않고, 일반 LRU 페이지를 회수할 때의 비용 대비 이 특수 캐시들을 파괴했을 때의 비용을 정교한 수식으로 저울질하며, 캐시 크기를 얼마나 줄이는 것이 시스템 전체에 가장 유리할지 그 타겟 수치를 치밀하게 계산해 냅니다.

메모리 할당이 처참하게 실패하고 나서야 허겁지겁 회수를 시작하는 수동적인 전략은 프로덕션 시스템에서 시한폭탄과 다름없습니다. 커널의 어떤 경로(path)들은 실행 도중 절대로 잠들어서는 안 되며(non-blocking), 이미 치명적인 락(lock)이나 핵심 자원을 선점한 상태라면 느릿느릿한 디스크 I/O를 기다릴 여유조차 없습니다. 따라서 Linux 커널은 폭풍우가 몰아치기 전에, 항상 일정 수준의 여유 방벽(free page)을 백그라운드에서 묵묵히 다져놓는 예방적 접근을 취합니다.

이 선제적 방벽 구축의 주인공은 단연 kswapd 커널 스레드입니다. 거대한 NUMA 아키텍처를 고려하여 각 메모리 노드마다 배속된 이 수호자들은 평상시엔 이벤트 대기열(wait queue)에서 코를 골며 잠들어 있습니다. 그러나 각 구역의 여유 공간이 pages_low 아래로 추락하는 순간 화들짝 깨어납니다. 기상과 동시에 이들은 balance_pgdat() 함수를 호출하여 앞서 배운 우선순위 12부터 0까지의 촘촘한 빗질(shrink_zone, shrink_slab)을 시작하고, 수위가 pages_high라는 안도선에 도달할 때까지 최소 32페이지 묶음 단위로 쉬지 않고 메모리를 확보해 나갑니다.

한편, 스왑 데몬 옆에는 구석구석을 쓸고 닦는 또 다른 정원사 cache_reap()이 존재합니다. 이 친구의 주 임무는 slab allocator 내부에 흩어진, 아무도 쓰지 않는 껍데기 객체(unused slab)들을 주기적으로 거두어들이는 것입니다. 미리 정의된 워크 큐(work queue) 스케줄러에 의해 약 2초마다 기계적으로 깨어나며, 로컬 CPU 캐시와 시스템 공유 캐시에 고인 자원들을 쓸어내리고 휴리스틱 공식을 돌려 얼마나 많은 빈 슬랩을 파괴할지 각을 잽니다. 계산이 끝나면 free slab 리스트를 돌며 가차 없이 slab_destroy를 연사하여 파편화된 빈 공간을 큼직한 가용 메모리로 뭉쳐냅니다.

PFRA가 땀을 비 오듯 쏟으며 모든 페이지를 쥐어짜고 캐시를 부숴도, 요구되는 메모리양이 물리적 한계를 아득히 초과한다면 시스템은 멈출 수밖에 없습니다. 이 절망적인 한계 상황에서 커널이 꺼내 드는 차갑고 잔혹한 최후의 수단, 그것이 바로 OOM(Out-Of-Memory) killer입니다. 메모리가 고갈되었다는 사형 선고인 out_of_memory()가 울려 퍼지면, 사형 집행인인 select_bad_process()가 차가운 눈빛으로 희생양을 물색하기 시작합니다.

완전한 파국(OOM)은 아니지만 시스템이 늪에 빠져 끔찍하게 느려지는 또 다른 치명적 질병이 있습니다. 바로 Swap Thrashing(스왑 스래싱)입니다. 이는 PFRA가 피눈물 흘려가며 기껏 스왑 아웃시켜 빈 공간을 만들었더니, 야속한 사용자 프로세스가 0.1초도 안 되어 그 페이지에 다시 접근(page fault)하여 디스크에서 꾸역꾸역 스왑 인(swap-in) 해오는 악순환이 무한 반복되는 현상입니다. 이 상태에 빠지면 CPU는 연산은 하지 못하고 디스크 I/O를 기다리며 헛돌게 됩니다. 이를 구제하기 위해 고안된 우아한 해결책이 Swap Token (스왑 토큰)입니다. 이 황금 토큰을 부여받은 프로세스의 소유 페이지는 일정 시간 동안 PFRA의 무자비한 강등 압박(inactive list로의 추락)으로부터 어느 정도 면책 특권을 받게 됩니다. 이렇게 밀어주기를 통해 토큰을 쥔 프로세스가 스래싱 없이 빠르게 연산을 끝마치고(진전을 이루고) 스스로 종료되어, 한꺼번에 방대한 메모리를 자연스럽게 뱉어내도록 유도하는 고도의 정치적 전략입니다.

디스크 상의 어떤 파일에도 자신의 그림자를 드리우지 못한 anonymous page를 메모리 밖으로 쫓아내야만 할 때, 그 안의 소중한 데이터들은 허공으로 증발해야 할까요?

그 해답은 바로 Swap Area(스왑 영역)에 있습니다. 동적으로 할당된 Heap이나 프로세스의 로컬 변수를 담고 있는 Stack 같은 익명 페이지들은, 매핑된 파일이 없으므로 날려버리면 영영 복구할 길이 없습니다. 따라서 커널은 이 페이지들을 강제로 압수하기 직전에 하드 디스크에 미리 떼어놓은 특별한 스왑 파티션(swap partition)이나 스왑 파일(swap file) 구석에 그 내용물을 고스란히 복사해 두는 백업 작업을 수행합니다. 익명 페이지 외에도, 여러 프로세스가 꼼지락대며 더럽혀놓은(dirty) private memory 매핑 페이지나, 프로세스 간 통신을 위해 뚫어놓은 IPC shared memory 페이지들 역시 갈 곳이 없어 스왑 영역이라는 대피소로 향하는 주요 손님들입니다.

스와핑 기법의 철학적 전제는 '완벽한 투명성(transparency)'입니다. 사용자 응용 프로그램은 자신의 데이터가 RAM에 있는지 하드 디스크 구석에 처박혀 있는지 전혀 눈치채선 안 됩니다. 커널은 이 환상을 유지하기 위해 마술을 부리는데, 그 트릭의 핵심이 PTE(Page Table Entry)에 달린 Present flag입니다. 페이지가 RAM에 무사히 살아있다면 이 비트는 1(set)을 가리킵니다. 하지만 스왑 아웃되어 디스크로 유배를 떠나는 순간, 커널은 이 비트를 0(clear)으로 내리고, 그로 인해 남게 된 PTE의 빈 비트 공간들에 "이 페이지는 스왑 파티션 X번의 Y번째 슬롯에 잠들어 있다"는 Swapped-out page identifier (스왑 위치 식별자)를 빼곡히 적어 넣습니다. 훗날 무지한 프로세스가 그 주소를 읽으려 접근하면 당연히 CPU는 하드웨어 예외(page fault)를 터뜨리게 되고, 커널의 듬직한 fault handler가 달려와 PTE의 암호를 해독한 뒤 디스크에서 먼지 묻은 데이터를 건져내어 다시 RAM으로 우아하게 스왑 인(swap-in) 시켜줍니다.

활성화되어 가동 중인 각각의 스왑 영역(파티션이나 파일)들은 커널 메모리 내부에서 swap_info_struct라는 거대한 디스크립터 구조체로 대표됩니다. 이 구조체의 심장부에는 swap_map이라는 거대한 카운터 배열이 자리 잡고 있는데, 스왑 영역에 존재하는 수백만 개의 페이지 슬롯 하나하나마다 전담 카운터가 하나씩 배정된 꼴입니다. 특정 슬롯의 카운터 값이 0이라면 그 방은 현재 먼지만 날리는 빈방(free slot)이라는 뜻이고, 양수(1 이상)라면 현재 그 데이터를 공동으로 소유하고 기대고 있는 참조자(owner) 프로세스의 숫자를 나타냅니다. 특이하게도 최대치인 SWAP_MAP_MAX 값이 찍혀 있다면 영구적으로 지워지지 않는 데이터라는 뜻이고, 불길한 SWAP_MAP_BAD 값이 찍혀 있다면 그 부분의 하드 디스크 표면에 물리적인 스크래치(배드 섹터)가 발생하여 접근해선 안 되는 망가진 슬롯임을 커널에 경고하는 것입니다.

이번에는 텅 비어버린 PTE 자리에 박히는 암호표, Swapped-out page identifier의 해부도를 살펴봅시다. 앞서 말했듯 이 마법은 PTE의 Present 비트를 0으로 뭉개면서 시작됩니다. 그러고 나면 PTE에 남은 수십 개의 잉여 비트 공간이 생기는데, 커널은 이 공간을 반으로 갈라 한쪽에는 "이 페이지가 갇혀있는 스왑 파티션의 고유 번호"를, 다른 한쪽에는 "그 파티션 내부의 몇 번째 방(page slot index)인지"를 꼼꼼하게 새겨 넣습니다. 이로써 CPU가 바라보는 PTE의 운명은 세 가지로 극명히 갈립니다. PTE 비트가 통째로 모두 0(null)이라면 이는 태초에 물리 프레임을 할당조차 받은 적 없는 처녀지(unallocated)이고, Present 비트는 0인데 나머지 비트에 요상한 좌표 숫자들이 적혀 있다면 "스왑 디스크로 이사 갔으니 데려와라"라는 뜻이며, Present 비트가 당당히 1로 빛나고 있다면 현재 눈부신 RAM 위에서 활발히 뛰놀고 있는 건강한 페이지임을 방증합니다.

부모 자식 간에 공유된 익명 페이지(shared anonymous page)가 스왑 아웃될 때는 조금 독특한 일이 벌어집니다. 찢겨나간 여러 개의 프로세스 PTE가 모두 단 하나의 동일한 스왑 디스크 슬롯을 가리키는 복제된 identifier를 지니게 됩니다. 이때 swap_duplicate() 함수가 호출되어 디스크 슬롯의 swap_map 카운터를 슬쩍 +1씩 증가시키며, "이 좁은 방 하나를 여러 명이 주시하고 있으니 함부로 지워선 안 된다"는 참조 횟수 추적의 막중한 책임을 다하게 됩니다.

시스템 관리자가 터미널에 swapon 명령어를 쳐서 메마른 대지에 단비를 내리려 할 때, 커널의 막후에서는 sys_swapon()이라는 거대한 의식이 치러집니다. 이 함수는 가장 먼저 명령을 내린 자가 정말로 시스템을 좌지우지할 권한(CAP_SYS_ADMIN)이 있는지 엄격하게 신분증을 검사합니다. 자격이 확인되면, 시스템 전역에 할당된 swap_info 배열을 훑으며 아직 아무도 선점하지 않은 텅 빈 디스크립터 자리를 하나 꿰찹니다. 그리고 지정된 파티션의 맨 앞, 슬롯 0번지에 기록된 헤더를 더듬어 읽고 "SWAPSPACE2"라는 약속된 매직 암호가 똑똑히 적혀 있는지 확인하여 엉뚱한 디스크를 포맷하는 참사를 방지합니다. 마지막으로 그 파티션의 크기만큼 vmalloc을 호출해 swap_map 카운터 배열이라는 거대한 장부를 메모리에 펼쳐내고, 마침내 승인 도장인 SWP_ACTIVE를 쾅 찍어 스왑 영역을 공식적으로 개장합니다.

반면, sys_swapoff()를 통한 비활성화 선언은 차원이 다른 복잡한 재앙과도 같습니다. 단순히 셔터를 내린다고 끝날 일이 아니라, 그 스왑 파티션 안에 아직 수십수백 개 프로세스의 잃어버린 고아 페이지들이 잠들어 있을 수 있기 때문입니다. 건물을 철거하기 전에 세입자들을 모두 밖으로 빼내야 하듯, 커널은 눈물을 머금고 try_to_unuse()라는 극한 직업 함수를 투입합니다. 이 함수는 swap_map 장부 전체를 이 잡듯이 뒤져 누군가 사용 중(카운터>0)인 슬롯을 끈질기게 찾아내고, 해당 데이터를 꾸역꾸역 좁아터진 RAM으로 다시 길어 올린(swap-in) 뒤, 시스템 전체의 프로세스 PTE를 모조리 뒤져 그 식별자(identifier)를 갖고 있던 녀석들의 주소를 방금 퍼 올린 실제 RAM 주소로 일일이 바꿔 끼우는 노가다를 수행해야만 비로소 파티션의 숨통을 끊을 수 있습니다.

전역 공간에서 새로운 빈방을 구하는 get_swap_page() 함수는 시스템에 활성화된 모든 스왑 파티션을 대상으로 매물을 검색합니다. 이때 무작정 첫 번째 파티션만 편애하지 않고, 관리자가 지정한 priority(우선순위)가 높은 고속 SSD 스왑 파티션부터 훑어봅니다. 만약 우선순위가 동일한 파티션이 여러 개 묶여 있다면, 특정 디스크만 과로사하지 않도록 라운드 로빈(round-robin) 방식으로 공평하게 슬롯을 뽑아 쓰는 세심함을 보여줍니다. 반대로 세입자가 방을 비우는 swap_free() 함수가 호출되면, 해당 슬롯의 swap_map 카운터를 단순히 -1 깎아주며, 이 카운터가 완전히 0으로 떨어지는 순간 그 슬롯은 다시 티 없이 맑은 공실(free slot)로 초기화됩니다.

두 프로세스가 동일한 anonymous page(예: 부모와 자식이 fork로 공유한 메모리)를 서로 나란히 공유하고 있는 흥미로운 상황을 가정해 봅시다. 어느 날 두 녀석이 약속이나 한 듯, 동시에 그 페이지에 접근하려 들어 page fault를 유발하고 경쟁적으로 swap-in을 시도한다면 무슨 일이 벌어질까요? 끔찍하게도 디스크에서 같은 데이터를 두 번 읽어와 물리 메모리상에 두 개의 독립된 쌍둥이 페이지 프레임으로 쪼개져 버리는(데이터 불일치) 대참사가 일어날 수 있습니다. 또 다른 시나리오로, 커널의 PFRA가 시스템을 살리겠다고 특정 페이지를 디스크로 내보내는(swap-out write) 와중에, 눈치 없는 다른 프로세스가 그 페이지가 필요한 줄 알고 읽어 들이려(swap-in read) 달려든다면 읽기와 쓰기 파이프라인이 무참히 꼬여버리고 맙니다. 이 혼돈의 레이스 컨디션(race condition)을 철통같이 방어하기 위한 커널의 유일무이한 황금률은 매우 간결합니다.

귀환의 최선봉장 read_swap_cache_async()의 꼼꼼함은 혀를 내두를 정도입니다. 녀석은 다짜고짜 디스크부터 읽지 않고 무조건 radix tree 대합실부터 조회합니다. 만약 텅 비어있어 새 물리 프레임을 할당받아 캐시에 방을 잡으려는 찰나, 그 수 마이크로초의 틈을 타고 경쟁자 프로세스가 번개처럼 같은 페이지를 캐시에 찔러 넣었을 수 있습니다. 놀랍게도 커널은 이때 화내지 않고, 자신이 방금 힘들게 할당받은 빈 프레임을 미련 없이 쓰레기통에 버린 뒤, 처음 조회 단계(lookup)로 조용히 롤백하여 경쟁자가 올려둔 페이지에 무임승차합니다. 이 지독하리만치 집요한 확인 및 재시도 로직 덕분에, 동일한 쫓겨난 페이지(swapped-out)에 대해서는 시스템 전체를 통틀어 단 하나의 유일무이한 페이지 프레임만이 존재하도록 완벽한 동기화(Synchronization)의 기적이 완성되는 것입니다.