토르발즈가 Claude Code를 이용해 리눅스 페이지 캐시 수정 시도, 하지만 경합 상태 발견
요약
리누스 토르발즈가 Anthropic의 Claude Code의 도움을 받아 리눅스 페이지 캐시 성능 개선 패치를 제출했습니다. 이 패치는 일반적인 읽기 경로에서 참조 카운트 작업을 제거하는 내용을 담고 있습니다. 하지만 검토 과정에서 경합 상태(race condition)와 메모리 회수 관련 우려가 제기되었습니다.
핵심 포인트
- Claude Code를 활용하여 리눅스 커널 성능 개선 시도.
- 페이지 캐시의 참조 카운팅 병목 현상 해결을 목표로 함.
- 검토자들은 경합 상태(race condition) 및 메모리 회수 문제를 발견함.
리누스 토르발즈가 Claude Code로 리눅스 페이지 캐시를 수정하다. 그러자 검토자들이 경합 상태를 발견했다.

리눅스 창시자이자 오랜 리드 개발자인 리누스 토르발즈는 개발자들이 2년 넘게 어려움을 겪어온 커널 성능 문제 해결을 위해 Anthropic의 Claude Code에 의존했습니다. 그는 화요일, 자신의 Ryzen Threadripper에서 실행된 합성 벤치마크에서 23배의 처리량 개선을 가져오는 10개 패치 시리즈를 제출했습니다.
토르발즈는 페이지 캐시 참조 카운팅 병목 현상에 대한 자신이 만든 수정 버전이 작동하지 않는 상태로 18개월을 보냈으며, 다른 개발자들은 자신들의 접근 방식에서 문제를 겪었습니다. 새로운 패치는 일반적인 버퍼링된 읽기 경로(buffered-read path)에서 folio 참조 카운트 작업을 제거하지만, 토르발즈는 실제 워크로드에서는 벤치마크상의 이득이 상당히 작을 것이라고 경고했습니다.
검토자들은 이후 경합 상태(race condition)를 식별했고 메모리 회수(memory reclamation)에 대한 우려를 제기했습니다. 토르발즈는 이전에 같은 병목 현상 작업을 했던 리눅스 커널 개발자인 Kiryl Shutsemau에게 추가 개발을 맡겼습니다.
토르발즈는 페이지 캐시 참조 카운팅 병목 현상에 대한 자신이 만든 수정 버전이 작동하지 않는 상태로 18개월을 보냈으며, 다른 개발자들은 자신들의 접근 방식에서 문제를 겪었습니다.
페이지 캐시 경합 문제
Hardware Busters에 따르면, 토르발즈의 Core i7-8565U 노트북에서는 folio 참조 카운트 경합이 8스레드 테스트에서 크로스 코어 부하 HITMs의 99.92%를 차지했습니다.
이 병목 현상은 Oracle 엔지니어이자 오랜 리눅스 커널 메모리 관리 개발자인 Matthew Wilcox가 고객 워크로드에서 나타난 후 2024년에 플래그를 지정했습니다.
Claude Code가 패치를 작성하다
일요일에 Phoronix의 Michael Larabel은 토르발즈의 트리에 noref-filemap-read-with-llm이라는 실험적인 브랜치(branch)를 발견했는데, 이 트리는 주 개발 브랜치 외에는 거의 아무것도 포함하지 않습니다.
8개의 패치 시리즈는 Linux 7.3-rc6을 기반으로 하며, Claude Code가 무엇을 했는지 명확하게 설명했습니다. Torvalds는 이 어시스턴트가 구현(implementation), 테스트(tests), 초기 문서화(initial documentation)를 작성했으며, 자신의 지휘 아래 코드를 검토했다고 말했습니다. 그는 과거에 AI가 코드의 99%를 작성한다고 주장하는 개발자들을 비판했음에도 불구하고 직접 벤치마크를 실행했습니다.
이전 접근 방식들은 폴리오 참조(folio reference)를 유지하지 않고 데이터를 복사한 다음 나중에 그 유효성을 확인하여, 회수(reclamation) 및 교체(replacement)와 관련된 경합 상태(races)를 남겼습니다. 이후의 10개 패치 rcu-free-v3 시리즈는 대신 새로운 PG_rcu_free 플래그와 RCU 지연 회수(RCU-delayed reclamation)를 사용하여, 폴리오가 사용자 공간 복사(userspace copy)를 통해 보호되도록 하며, 이 과정에서 오류(fault)가 발생하지 않는 경우에 한합니다.
이전 접근 방식들은 폴리오 참조를 유지하지 않고 데이터를 복사한 다음 나중에 그 유효성을 확인하여, 회수 및 교체와 관련된 경합 상태를 남겼습니다.
Threadripper 벤치마크 결과
원래의 8개 패치 브랜치는 Torvalds의 노트북에서 처리량(throughput)을 거의 세 배로 늘려, 8스레드 성능을 1,000만 회에서 최대 3,300만 회/초까지 끌어올리는 동시에 커널 읽기당 사이클 수를 대략 2,950회에서 725회로 줄였습니다. 수정된 시리즈는 그의 64스레드 Threadripper에서 무거운 경합 상태(heavy contention) 하에 훨씬 더 큰 이득을 제공했는데, 여기서 처리량은 1,330만 회에서 3억 4백만 회/초까지 급증했고 읽기당 사이클 수는 거의 20,000회에서 735회로 감소했습니다.
원래의 8개 패치 브랜치는 Torvalds의 노트북에서 처리량을 거의 세 배로 늘려, 8스레드 성능을 1,000만 회에서 최대 3,300만 회/초까지 끌어올리는 동시에 커널 읽기당 사이클 수를 대략 2,950회에서 725회로 줄였습니다.
성능 향상은 트레이드오프를 동반했습니다. 첫 번째 구현에서는 지연된 회수(delayed reclamation)가 CPU가 1,024 페이지 이상을 대기열에 넣을 때마다 신속한 유예 기간(expedited grace period)을 강제하도록 했습니다. Hardware Busters의 보고서에 따르면, 매핑되지 않은 사용자 페이지로 읽는 작업 또한 기존 경로로 폴백하기 전에 추가적인 오류(fault)를 발생시켰고, 이는 16바이트 단일 스레드 읽기 시간을 약 4,150 사이클에서 6,550 사이클로 증가시켰습니다. 이러한 회귀가 rcu-free-v3에서도 지속될지는 불분명합니다.
유지보수자들은 회수 설계에 의문을 제기하다
Wilcox는 새로운 PG_rcu_free 플래그에 대해 의문을 제기하며, 대신 페이지 유형(page type)을 사용하고 RCU 유예 기간 이후 비활성 목록 폴리오(inactive-list folios)를 회수할 것을 제안했습니다.
Torvalds는 두 접근 방식 모두 거부했는데, 플래그가 여전히 사용자 공간에 매핑될 수 있는 동안 설정되어야 하며, 비활성 목록 회수가 truncate 및 hole-punch 작업들을 포괄하지 못한다고 주장했습니다. Shutsemau는 이후 이 플래그를 64비트 시스템으로 제한할 것을 제안했고, 이는 Arm 엔지니어이자 리눅스 메모리 관리 유지보수자인 David Hildenbrand가 지지한 접근 방식입니다.
Shutsemau는 또한 filemap_read_rcu_batch()에서 경합 상태(race)를 식별했습니다. 이 경우 폴리오 대체(folio replacement) 후 i_size 확장이 이루어지면서 한 번도 쓰여지지 않은 데이터를 노출할 수 있었습니다. Torvalds는 파일 크기 읽기를 더 일찍 수행하고 폴리오 검사를 통합할 것을 권장했고, Shutsemau는 이를 수정된 패치에 반영했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 HN OpenAI Codex의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기