프로파일러를 프로파일링했더니 커널 버그가 나왔다 — eBPF map-in-map 8년 묵은 성능 버그 수정기

• CPU 프로파일러 Superluminal 개발팀이 자기네 프로파일러로 자기네 프로파일러를 프로파일링하다가 리눅스 커널의 8년 묵은 성능 버그를 발견하고 패치까지 제출한 이야기

eBPF와 map-in-map

• Superluminal의 Linux 버전은 eBPF를 통해 성능 데이터(컨텍스트 스위치, 샘플링 이벤트 등)를 수집함. 스택 언와인딩에 필요한 .eh_frame 데이터를 유저스페이스에서 eBPF 프로그램으로 업로드하는데, 이 데이터를 BPF_MAP_TYPE_ARRAY_OF_MAPS (2D 배열과 비슷한 구조)에 저장

• 프로파일링 시작 전에 약 1,400개의 바이너리에 대한 언와인드 데이터를 프리캐싱하는데, 32코어 머신에서 31개 스레드로 병렬 처리해도 830ms나 걸림. 실제 작업량으로 치면 약 25초

병목 발견: "프로파일러를 프로파일링하라"

• 프로파일링 결과, 시간의 대부분이 bpf_map_update_elem에서 소비됨. 평균 호출당 18ms, 총 25초. 그런데 이 함수가 실제로 코드를 실행하는 게 아니라 대기 상태임

• 커널 소스를 추적해보니 원인은 maybe_wait_bpf_programs 함수. map-in-map 타입에 대해서만 synchronize_rcu()를 호출하는데, 이게 RCU(Read-Copy-Update) 시스템의 quiescent state에 도달할 때까지 블로킹하는 함수임

왜 이런 코드가 있었나

• 2018년에 추가된 코드로, map-in-map의 더블 버퍼링 패턴에서 발생하는 레이스 컨디션을 방지하기 위한 것. 유저스페이스가 map의 값을 교체할 때, 아직 이전 값을 사용 중인 eBPF 프로그램이 있을 수 있으니 모든 프로그램이 새 값을 쓸 때까지 기다리겠다는 의도

• 원래 메일링 리스트에서는 옵트인 플래그로 제안됐지만, 커널 메인테이너가 "비용이 작으니 기본으로 하자"며 무조건 동기화하는 방향으로 결정. 결과적으로 그 "작은 비용"이 8~20ms의 블로킹이었던 거임

해결: synchronize_rcu_expedited

• 기존 동작을 바꾸면 "WE DO NOT BREAK USERSPACE" 원칙에 위배되므로 제거는 불가. 배치 업데이트(bpf_map_update_batch)도 검토했지만, 동적 라이브러리 로딩 등 배칭이 안 되는 경우가 있어 범용 해결책이 필요했음

• 커널 메일링 리스트에서 누군가 synchronize_rcu_expedited를 제안. 직접 커널을 컴파일해서 테스트한 결과:

  • 프리캐시 전체 시간: 830ms → 26ms (31배 빠름)
  • bpf_map_update_elem 평균: 18ms → 59μs (305배 빠름)

• 이 패치는 수락되어 리눅스 6.19 커널에 반영 예정. BPF_MAP_TYPE_ARRAY_OF_MAPS나 BPF_MAP_TYPE_HASH_OF_MAPS를 쓰는 모든 eBPF 프로그램이 자동으로 혜택을 받게 됨

왜 8년간 발견되지 않았나

• 리눅스에서 성능 분석할 때 "on-cpu" 프로파일링(실행 중인 코드 분석)이 기본이고, "off-cpu" 프로파일링(대기 중인 스레드 분석)은 별도로 설정해야 함. perf의 기본 설정은 샘플링만 기록하므로 이 병목은 보이지 않음

• 실제로 이 문제를 알고 난 후 perf 샘플링 모드로 같은 병목을 찾아보니, bpf_map_update_elem이 거의 시간을 안 쓰는 것처럼 보였음. 함수가 코드를 실행하는 게 아니라 대기하고 있었기 때문. Superluminal은 on-cpu와 off-cpu를 항상 같이 수집하기 때문에 바로 발견할 수 있었다는 거임