HugeTLB와 THP의 장점을 결합하기 위해 Linux에 제안된 Reserved THP 기능

ByteDance는 Linux 커널 내의 커널 Huge Page를 위해 HugeTLB와 Transparent Huge Page (THP) 지원을 통합하기 위한 잠재적인 디딤돌 또는 목표로서 Reserved THP를 연구해 왔습니다. HugeTLB는 예약 (reservation) 및 예약된 풀 (reserved pools) 내에서의 보장된 할당 (guaranteed allocation)과 같은 좋은 요소들을 제공하지만, 스왑 (swap)을 지원하지 않습니다. 반면, THP는 예약 기능을 지원하지 않고 할당이 보장되지 않지만, 핵심 메모리 관리 코드와 더 밀접하게 통합되어 있으며 스왑을 처리할 수 있습니다.

Qi Zheng은 Reserved THP 아이디어를 고안하게 된 경험에 대해 다음과 같이 설명했습니다:

"우리의 내부 시나리오에서는 사용자 프로세스가 핫 업그레이드 (hot-upgrade) 요구 사항으로 인해 Hugetlb 메모리 양의 두 배를 예약해야 합니다. 예를 들어, 프로세스에 16GB의 Hugetlb이 필요한 경우, 메모리 할당을 충족하기 위해 핫 업그레이드 중에 추가로 16GB가 필요합니다. 업그레이드 후에는 이전 프로세스가 종료되어 16GB의 HugeTLB를 해제합니다. 따라서 대부분의 경우, 추가된 16GB의 HugeTLB는 낭비됩니다.

간단한 아이디어는 Hugetlb CMA 기능을 사용하여 총 32GB의 hugetlb_cma를 예약하는 것입니다. 정상 작동 중에는 16GB가 소비되고, 나머지 16GB는 다른 프로세스에 의해 사용될 수 있습니다. 핫 업그레이드 중에 다른 프로세스가 사용하는 메모리를 마이그레이션하여 필요한 추가 16GB의 Hugetlb을 할당하도록 시도할 수 있습니다. 이것이 작동할 수도 있지만, 여전히 32GB의 메모리를 예약해야 합니다.

우리는 또한 핫 업그레이드 중에 이전 프로세스의 hugetlb 중 약 10GB가 실제로는 콜드 메모리 (cold memory)이며, 이론적으로 회수 (reclaim)될 수 있다는 것을 발견했습니다. 극단적인 경우, 22GB의 메모리만 예약하고 핫 업그레이드 중에 나머지 10GB를 회수할 수 있습니다. 하지만 불행하게도 hugetlb은 현재 스왑을 지원하지 않으며, 이를 지원하는 것은 상당히 어려워 보입니다."

따라서 우리는 예약 가능한 THP인 "reserved THP"를 도입할 수 있을지 고민하고 있습니다. 이는 일반적인 메모리 할당(memory allocation)으로는 소비할 수 없는 반면, madvise()와 같은 메서드를 통해 소비될 수 있습니다. 이를 통해 hugetlb과 유사한 효과를 달성할 수 있습니다. 또한 THP이기 때문에 스왑(swap) 기능을 비교적 쉽게 지원할 수 있으며, 이는 앞서 언급한 문제를 완벽하게 해결합니다.

지난 몇 년 동안 THP와 HugeTLB를 통합하기 위한 커널 논의가 있었으나, 현재까지는 여전히 분리된 상태로 남아 있습니다.

이 Reserved THP 제안에 대해 더 자세히 알고 싶은 분들은 이 LKML 패치 시리즈를 통해 확인할 수 있습니다.