제안 당시의 병목과 현재 구현
2021년 Oracle 글은 당시 VMA를 red-black tree와 이중 연결 목록에 두고, 빈 주소 범위를 찾기 위한 정보도 관리했다고 설명합니다. 트리 검색과 순서 순회, VMA 분할·병합이 모두 자주 일어나므로 자료구조의 배치와 잠금 경쟁이 중요하다는 문제 제기입니다.
그 글의 마지막에 적힌 “RCU 비활성화”, 32비트 미지원, 연결 목록 존속은 2020년 RFC의 미완성 상태입니다. 이를 Linux 6.18의 현재 제약으로 옮기면 틀립니다. 현재 커널 문서는 Maple Tree가 RCU 안전 모드를 지원한다고 설명하고, 프로세스 주소 공간의 각 mm_struct가 VMA를 Maple Tree로 관리한다고 명시합니다.
주소 하나와 연속 범위를 같은 트리에서 찾습니다
Maple Tree는 겹치지 않는 범위를 저장하도록 최적화한 B-tree입니다. VMA 하나는 가상 주소의 연속 구간을 설명하지만 실제 물리 페이지가 모두 준비됐다는 뜻은 아닙니다. 트리의 역할은 어느 VMA가 한 주소를 포함하는지, 다음 VMA가 어디인지 찾는 것입니다.
일반 API의 mtree_load()는 한 인덱스에 놓인 항목을 찾고 mt_find()는 그 지점 이후의 항목을 찾습니다. 범위 저장·삭제와 반복도 지원합니다. VMA처럼 순회 중 현재 구간의 양 끝이 필요하면 고급 API의 ma_state가 index와 last를 유지합니다. 트리를 직접 쓰는 코드와 커널의 VMA 전용 반복자를 혼동하지 않아야 합니다.
- 가상 주소
주소가 어느 VMA 범위에 속하는지 검색
- Maple Tree
겹치지 않는 범위·다음 항목·선택적 빈 공간 정보
- VMA 객체
접근 경로에 맞는 락으로 메타데이터와 수명을 보호
- 페이지 테이블
접근할 때 실제 매핑·page fault 경로에서 별도 처리
단계는 서로 다른 책임을 뜻하며, 앞 단계가 성공했다고 해서 다음 단계가 완료되는 것은 아닙니다.
빈 공간 검색은 선택한 트리 모드에 달려 있습니다
Maple Tree는 MT_FLAGS_ALLOC_RANGE로 초기화한 allocation tree에서 빈 범위 탐색을 지원합니다. mas_empty_area()는 낮은 주소부터, mas_empty_area_rev()는 높은 주소부터 필요한 크기의 빈 공간을 찾습니다. 일반 트리와 allocation tree는 내부 분기 특성이 달라, 모든 Maple Tree가 같은 빈 공간 인덱스를 유지한다고 가정하면 안 됩니다.
VMA를 삽입할 후보 주소를 골랐다고 해서 페이지 테이블이 채워지는 것도 아닙니다. 빈 가상 주소를 찾았다고 해서 해당 주소에 물리 페이지가 매핑되거나 접근 권한이 확정된 것은 아닙니다.
RCU 안전한 검색과 VMA 수명 보호를 분리합니다
일반 Maple Tree API의 읽기 함수는 내부적으로 RCU 읽기 구간을 사용할 수 있고, 쓰기는 내부 락 또는 설정된 외부 락으로 직렬화합니다. 하지만 검색 함수가 반환한 VMA 포인터를 RCU 구간 밖에서도 안전하게 역참조할 수 있다는 뜻은 아닙니다. 고급 API를 직접 쓰면 호출자가 잠금 규칙을 책임집니다.
Linux 6.18의 프로세스 주소 공간 문서는 VMA 메타데이터를 읽을 때 mmap_read_lock()을 유지하거나 lock_vma_under_rcu()로 VMA별 읽기 락을 얻으라고 안내합니다. 후자가 실패하면 mmap 읽기 락 경로로 되돌아가야 합니다. 역매핑의 잠긴 interval tree를 순회한다면 적절한 rmap 락으로 VMA를 안정화하는 별도 경로도 있습니다. 대부분의 VMA 메타데이터 쓰기에는 mmap 쓰기 락과 대상 VMA 쓰기 락이 필요합니다. 트리의 RCU 안전성과 개별 VMA의 안정성을 한 단계로 취급하지 않습니다.
코드 검수에서 확인할 경계
현재 커널 코드를 검토할 때는 주소 검색, 범위 순회, 빈 공간 탐색 중 무엇을 하는지 먼저 적습니다. 다음으로 regular/allocation tree 모드, 일반/고급 API, mm과 VMA의 잠금 및 포인터 수명, 트리를 수정할 때 메모리를 할당할 수 있는지를 확인합니다.
이 글은 자료구조와 잠금의 개념 경계를 설명합니다. 2021년 글의 노드 크기·분기 수를 Linux 6.18의 고정 성능 수치로 재사용하거나, 특정 워크로드의 속도 향상을 재현했다고 주장하지 않습니다.