우리가 1GB의 RAM을 가지고 있다고 해서 커널이 "이 1GB를 내 마음대로 다 써야지"라고 할 수 있을까요? 그렇지 않습니다. 일부 공간은 하드웨어가 미리 예약하고, 또 다른 일부는 커널 자체의 코드와 고정된 자료구조가 차지하게 됩니다. 그렇다면 남은 귀중한 '동적 메모리'를 어떻게 낭비 없이, 빠르고 안전하게 나누어 줄 수 있을까요?

리눅스는 80x86 아키텍처에서 4KB 단위의 페이지 프레임을 표준 할당 단위로 사용합니다. 이렇게 하면 페이지 폴트 해석이 단순해지고, 디스크와 메모리 사이의 데이터 전송 효율도 높아지기 때문입니다. 오늘의 여정은 바로 "이 4KB짜리 페이지 프레임을 어떻게 추적하고 나누어 주는가?"에서 출발합니다.

수십만 개에 달하는 4KB 단위의 페이지 프레임을 하나하나 추적하기 위해, 리눅스는 각 페이지 프레임마다 일종의 이름표인 페이지 디스크립터(struct page)를 붙여둡니다. 이 디스크립터들은 mem_map이라는 거대한 배열에 순서대로 저장되며, 각 디스크립터는 32바이트 크기를 가져 전체 RAM 용량의 1%가 채 안 되는 공간만을 차지합니다.

복잡한 멀티프로세서 시스템에서는 CPU가 어느 위치의 메모리에 접근하느냐에 따라 물리적인 접근 속도가 미묘하게 달라집니다. 이런 구조를 가리켜 NUMA(Non-Uniform Memory Access) 모델이라고 부릅니다. 이 때문에 전체 물리 메모리는 여러 개의 노드(Node)로 나뉘며, 각 노드는 pg_data_t 구조체로 표현되어 체인처럼 연결됩니다. 다만 80x86 UMA 기반의 일반 PC에서는 커널 코드 구조의 일관성을 위해 전체를 단일 노드(node 0)로 취급합니다.

이렇게 나뉜 각 존은 자신만의 존 디스크립터(Zone Descriptor)를 가집니다. 여기에는 free_pages(남은 페이지 수), 수위 조절을 위한 세 가지 워터마크(pages_min, pages_low, pages_high), CPU별 전용 캐시인 pageset, 그리고 버디 시스템을 관장하는 free_area 등이 꼼꼼하게 기록되어 있습니다. 즉, 존은 단순한 주소의 범위가 아니라 "이 구역 안의 메모리를 어떻게 할당하고, 얼마나 아껴두며, 언제 부족함을 느낄 것인가"를 종합적으로 판단하는 핵심 관리 단위입니다.

인터럽트 핸들러나 임계 구역(Critical Region)처럼 도중에 멈추거나 잠들면 안 되는 코드에서는 대기 없이 즉각적으로 할당되는 원자적 할당(GFP_ATOMIC)이 반드시 필요합니다. 이런 요청이 실패하면 시스템이 치명적인 상태에 빠질 수 있으므로, 커널은 항상 최악의 상황을 대비해 예약 페이지 프레임 풀을 비워둡니다. 이 비상금의 최소 규모는 min_free_kbytes 변수에 담기며, 각 존이 관리하는 수위선(워터마크) 역시 이 값을 바탕으로 계산됩니다.

Figure 8-2의 논리적 구조를 위에서부터 내려다보면, 가장 상층부에 존 할당자(Zone Allocator)가 자리 잡고 있습니다. 그 아래로 각 존마다 단일 페이지 요청을 빠르게 처리하는 CPU별 페이지 프레임 캐시와, 연속된 여러 페이지를 묶어서 관리하는 버디 시스템(Buddy System)이 진을 치고 있습니다. 즉, 메모리 요청이 들어오면 존 할당자가 "어느 존에서 빼줄까"를 결정하고, 선택받은 존 내부의 버디 시스템이나 캐시가 실제로 메모리를 떼어주는 구조입니다.

커널 코드가 "메모리 좀 주세요"라고 요청할 때, 사실 그 이면에는 아주 까다로운 조건들이 함께 따라붙습니다. 이 조건들의 묶음표를 가리켜 gfp_mask라고 부릅니다.

이 중에서도 __GFP_DMA와 __GFP_HIGHMEM은 탐색 구역을 결정짓는 존 수식어(Zone Modifier)입니다. __GFP_DMA가 켜져 있으면 커널은 뒤도 돌아보지 않고 ZONE_DMA만 뒤집니다. 반면 __GFP_HIGHMEM이 켜져 있으면, 우선 ZONE_HIGHMEM을 찾아본 뒤 자리가 없으면 ZONE_NORMAL로, 거기도 없으면 최후에 ZONE_DMA로 내려오는 식의 유연한 탐색(Fallback)을 진행합니다. 왜 그럴까요? DMA 구역은 워낙 좁고 소중하기 때문입니다. 식당에 비유하자면 VIP 전용 좌석을 일반 손님에게 섣불리 내주었다가, 정작 VIP(구형 ISA 장치)가 도착했을 때 자리가 없어 쩔쩔매는 불상사를 막기 위함입니다.

결론적으로 "물리적 RAM 공간이 남아 있다"는 말과 "커널이 당장 선형 주소로 그 공간을 찔러볼 수 있다"는 말은 결코 동의어가 아닙니다. LOWMEM 영역은 언제든 곧바로 접근 가능하지만, HIGHMEM 영역은 창고 저 깊숙한 곳에 실존하더라도 커널이 다가가기 위해서는 잠시 '매핑 창문'을 열어주는 수고로움이 필요합니다.

영구 커널 매핑(Permanent Kernel Mapping)은 커널 선형 주소 공간의 끝자락에 위치한 128MB 구간 중 일부를 활용해 HIGHMEM 페이지와 연결하는 튼튼한 창문입니다. 임시 매핑에 비해 창문을 더 오래 열어둘 수 있다는 장점이 있지만, 만약 남은 빈 창문이 없다면 창문이 생길 때까지 현재 실행 중인 프로세스가 잠들며 대기해야 할 수도 있습니다. 그렇기 때문에 인터럽트 핸들러처럼 도중에 절대 잠들어선 안 되는 문맥(Context)에서는 이 매핑 방식을 사용할 수 없습니다.

임시 커널 매핑(Temporary Kernel Mapping)은 자리가 없다고 대기열에서 잠드는 법이 결코 없습니다. 따라서 인터럽트 핸들러나 지연 함수(Deferrable Function)에서도 안심하고 사용할 수 있습니다. 다만 동시에 사용할 수 있는 창문의 수가 극단적으로 적으며, 이 창문을 열고 작업을 하는 도중에는 절대로 다른 일로 빠지거나 잠들어서는 안 된다는 무서운 제약이 따릅니다.

호텔에 단체 손님이 와서 "연속된 빈 방 8개 주세요!"라고 외칩니다. 마침 호텔 전체에 빈 방은 20개나 남아 있었지만, 안타깝게도 모두 이리저리 흩어져 있어 손님을 받을 수 없었습니다. 메모리 세계에서도 이와 똑같은 비극이 일어나곤 하는데, 이를 외부 단편화(External Fragmentation)라고 부릅니다.

리눅스 커널은 이런 외부 단편화의 골칫거리를 해결하고자 연속된 자유 블록들을 아주 체계적으로 모았다가 쪼개는 '버디 시스템'을 곁에 두고 있습니다. 왜 굳이 연속된 공간에 집착할까요? 첫째, 특정 DMA 버퍼처럼 물리적으로 무조건 이어져 있어야만 작동하는 하드웨어가 있기 때문입니다. 둘째, 자잘하게 쪼개진 페이지들을 엮다 보면 페이지 테이블을 너무 자주 건드려야 하고, 이는 TLB flush라는 값비싼 비용으로 되돌아옵니다. 셋째, 큼직하게 이어진 물리 메모리는 '큰 페이지(Huge Page)' 기술과 맞물려 TLB 미스 확률을 획기적으로 낮춰주는 효자 역할을 톡톡히 하기 때문입니다.

버디 시스템은 현재 남아 있는 자유 페이지 프레임들을 크기별로 총 11개의 리스트에 꼼꼼히 나누어 담아둡니다. 여기서 order k라는 것은 2의 k제곱 크기를 가진 페이지 블록을 뜻합니다 (가령 가장 큰 order 10은 1024페이지, 즉 4MB의 덩치를 자랑합니다). 누군가 특정 크기의 블록을 요청했는데 마땅한 매물이 없다면 어떻게 할까요? 과감하게 한 단계 더 큰 블록을 반으로 뚝 잘라 내어주고, 나중에 사용이 끝나 반환될 때 혹시 옆집에 사는 짝꿍(buddy) 블록도 비어 있다면 잽싸게 하나로 합쳐 다시 덩치를 키우는 영리한 방식을 취합니다.

Linux 2.6에서는 모든 존(Zone)마다 각자의 독립적인 버디 시스템을 한 세트씩 거느리고 있습니다. 각 존 디스크립터 안에 자리한 free_area[k] 배열은 2^k 크기의 자유 블록들을 꿰어놓은 이중 연결 원형 리스트(free_list)와, 현재 그 크기 블록이 몇 개나 남아 있는지 세어둔 nr_free 정보를 품고 있습니다. 묶여 있는 수많은 페이지 중에서 가장 첫 번째 페이지 디스크립터만이 lru 필드를 동원해 앞뒤 블록과 손을 맞잡고, private 필드에 자신의 자랑스러운 크기(order)를 은밀히 새겨넣습니다.

고작 페이지 한 장을 달라고 할 때마다 거대한 버디 시스템 전체에 자물쇠(락)를 채우고 부산을 떠는 것은 너무나도 무겁고 비효율적입니다. 그래서 각 메모리 존은 CPU마다 자신만의 가벼운 전용 보관함인 'CPU별 페이지 프레임 캐시'를 곁에 두고 있습니다.

buffered_rmqueue() 함수는 누군가 order 0(단일 페이지)을 요청했을 때 이 per-CPU 캐시를 쓱 들여다봅니다. 요청 조건에 __GFP_COLD가 붙어 있다면 차가운 캐시 서랍을 열고, 없다면 따뜻한 캐시 서랍을 엽니다. 반대로 다 쓴 페이지가 되돌아올 때는 언제나 온기가 돌 것으로 간주하여 따뜻한 hot cache 서랍에 쏙 집어넣습니다.

존 할당자(Zone Allocator)의 핵심 지휘관은 단연 __alloc_pages(gfp_mask, order, zonelist)입니다. 이 지휘관은 여러 존이 나열된 리스트(zonelist)를 순찰하며, 각 존의 상태가 괜찮은지 zone_watermark_ok()를 통해 타진해 봅니다. 검문을 통과하는 존이 나타나면 곧장 buffered_rmqueue()에게 눈짓을 보내어 실제 메모리 할당을 시도하게 만듭니다.

한편 해제 절차를 맡은 __free_pages()는 참조 카운터(_count)를 하나 살짝 줄여보는 것으로 임무를 시작합니다. 깎아낸 뒤에도 여전히 0 이상이면 어딘가에서 쓰고 있다는 뜻이므로 가볍게 손을 털고 물러납니다. 완전히 비워졌다면, 덩치가 1장(order 0)일 땐 per-CPU의 따뜻한 캐시 서랍에 쏙 넣어두고, 여러 장 묶음이라면 원래 고향인 버디 시스템으로 너그럽게 돌려보냅니다.

커널이 매번 무식하게 4KB 크기의 큼직한 땅덩어리만 요구하는 것은 결코 아닙니다. 오히려 프로세스 디스크립터나 열려 있는 파일 객체처럼 불과 수십에서 수백 바이트 남짓한 자그마한 객체들을 쉴 새 없이 생성하고 폐기합니다. 만약 이런 조약돌 같은 객체 하나를 만들 때마다 버디 시스템을 졸라 4KB 페이지 전체를 독점하게 만든다면, 그 안에 남는 엄청난 잉여 공간들은 고스란히 버려질 것입니다. 바로 이런 어처구니없는 낭비를 내부 단편화(Internal Fragmentation)라고 꼬집습니다.

각각의 캐시(수납장)는 자신의 신상명세가 빼곡히 적힌 kmem_cache_t 디스크립터라는 꼬리표를 이마에 붙이고 있습니다.

수납장 안의 서랍(슬랩) 하나하나를 책임지는 슬랩 디스크립터 역시 만만치 않습니다. 여기엔 list(위의 세 갈래 길 중 자신이 어디 속했는지 연결하는 끈), colouroff(첫 객체를 놓을 위치의 미묘한 여백), s_mem(첫 알맹이 객체의 실제 메모리 주소), inuse(현재 몇 개의 방이 찼는지 세어둔 숫자), free(다음에 바로 손님을 밀어 넣을 빈방 번호) 필드가 존재합니다. 재미있는 것은 이 슬랩 디스크립터가 위치하는 장소입니다. 서랍 안에 넉넉하게 자리가 남으면 서랍 내부(internal) 한쪽에 셋방을 차리지만, 객체 덩치가 너무 커서 자리가 비좁으면 서랍 바깥(external)의 전혀 다른 일반 캐시로 쫓겨나 신세를 지기도 합니다.

수납장(캐시)을 탈탈 털어봐도 내줄 빈방(객체)이 하나도 없다면, 커널은 부리나케 cache_grow()를 호출하여 새로운 서랍(슬랩) 한 칸을 창조해 냅니다.

반대로 쓸모가 다해 서랍을 부술 때는 slab_destroy()가 나섭니다. 방마다 돌아다니며 소멸자(dtor)를 불러 말끔히 정리를 시킨 뒤, kmem_freepages()로 뼈대가 되었던 페이지 프레임들을 자연의 품(버디 시스템)으로 돌려보냅니다.

수많은 CPU 코어들이 밥 먹듯이 객체를 꺼내가려 할 때 메인 수납장 하나에만 매달리면, 락(Lock)을 걸고 푸느라 길바닥에 버리는 시간이 너무 길어집니다. 이 참사를 막기 위해 커널은 캐시마다 CPU 각자의 전용 냉장고, 이른바 보조 캐시(local cache)를 따로 분양해 주었습니다. 이 개인 냉장고 안에는 바로 꺼내 쓸 수 있는 자유 객체들의 포인터 배열이 얌전히 들어차 있습니다.

객체를 다 쓰고 버릴 때도 마찬가지입니다. kmem_cache_free()는 개인 냉장고에 쑤셔 넣을 자리가 있으면 가볍게 툭 던져놓고 퇴근합니다. 만약 한계치(limit)까지 꽉 차서 문이 닫히지 않는다면, cache_flusharray()를 불러 냉장고 속 객체들의 절반 정도를 공용 냉장고나 메인 서랍으로 우르르 반납해 속을 비워낸 뒤, 가져온 객체를 여유롭게 밀어 넣습니다.

메모리 풀(Memory Pool)은 블록 장치 서브시스템 같은 깐깐한 커널 부서들이 메모리가 극도로 메말라버린 비상사태에서도 생존할 수 있도록, 아주 적은 양의 비상식량을 따로 빼돌려 창고 깊숙이 은닉해 두는 기법입니다. 전역적으로 누구에게나 열려 있는 원자적 할당 풀과는 결이 다르게, 철저히 '특정 부서(소유자)'만을 위해 미리 파놓은 사제 비상 방공호에 가깝습니다.

그리고 대망의 비연속 메모리 영역(Noncontiguous Memory Area)입니다. 이 기법은 실제 물리적인 땅 조각(페이지 프레임)들은 뿔뿔이 흩어져 있더라도, 커널이 내려다보는 선형 주소 공간의 거울 속에서는 마치 거대한 하나의 덩어리로 이어진 것처럼 환상을 만들어냅니다. 외부 단편화에 얽매이지 않고 거대한 영역을 확보할 수 있다는 치명적인 장점이 있지만, 그 환상을 유지하기 위해 끊임없이 페이지 테이블을 주물럭거려야 하는 무거운 비용, 그리고 오직 4KB 배수 크기로만 놀아야 한다는 엄격한 제약이 뒤따릅니다.

이렇게 만들어진 환상을 깨부술 때는 vfree() 나 vunmap()이 출동합니다. __vunmap()의 지휘 아래 remove_vm_area()가 디스크립터를 뒤져서 페이지 테이블의 다리를 하나하나 끊어내고, 필요하다면 빌려왔던 물리 페이지 프레임들과 잡다한 관리용 배열(vm_struct 등)마저 깡그리 해제해 버립니다.