Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
bpf-bench는 eBPF 최적화를 위한 벤치마크 프레임워크입니다. 이 시스템은 LLM 에이전트를 활용하여 폐쇄 루프 검색 문제로 구성되어, 에이전트가 행동을 선택하고 실제 워크로드에서 성능 피드백을 받아 최적화 과정을 반복합니다. 이는 eBPF 컴파일 파이프라인의 안전한 확장을 목표로 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GitHub AI Tools의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기아티팩트 평가 (Artifact evaluation) (ATC 2026): 수락된 논문 BPF-Ext: Safely Extending the eBPF Compilation Pipeline with Native Operations의 평가자 지침은 다음 위치에 있습니다.
docs/atc26-artifact-evaluation.md. 이 GitHub 가이드를 시작점으로 사용하십시오. Zenodo에 변경 불가능한 아카이브 백업본이 보관되어 있습니다.
논문 BPF-Ext: Safely Extending the eBPF Compilation Pipeline with Native Operations (ACM ATC '26)은 다음을 가리킵니다. 해당 구성 요소들이 위치한 곳:
| 논문 부분 | 위치 |
|---|---|
| BPF-Ext 커널 지원 (검증기 낮추기 및 복원, x86-64 및 arm64 JIT) | vendor/linux-framework: eunomia-bpf/linux, 브랜치 kinsn-only |
| ... |
git clone https://github.com/eunomia-bpf/bpf-benchmark.git
cd bpf-benchmark
git submodule update --init --recursive -- \
...
단순히 git submodule update --init --recursive를 실행하지 마십시오: 네 개의 서브모듈(docs/paper, docs/kprog-simulator-in-ebpf, docs/speculative-optimization, vendor/academic-writing-skills)은 접근 권한 없이는 가져오기 실패하는 비공개 작성자 저장소이며, 문서화된 명령어 중 이들을 필요로 하는 것은 없습니다. 모든 서브모듈에 대해서는 THIRD_PARTY_NOTICES.md를 참조하십시오.
kinsn/README.md에서 설명하는 상위 커널 RFC는 나중의 재설계이며 이 아티팩트의 커널 코드가 아닙니다.
자동 연구 프레임워크 및 에이전트 기반 OS 커널 확장 최적화 벤치마크.
bpf-bench는 eBPF 최적화를 LLM(대규모 언어 모델) 에이전트를 위한 폐쇄 루프 검색 문제로 구성합니다. 에이전트는 최적화 행동을 선택하고, 프레임워크는 해당 행동들을 격리된 Docker/KVM/AWS 환경의 실제 애플리케이션 및 워크로드에 대해 실행하며, 각 반복마다 다음 결정을 위해 검증기(verifier), JIT 컴파일러, 워크로드, 그리고 성능 피드백을 반환합니다.
이 저장소는 docs/ebpf27-bpfoptbench/에 있는 bpf-bench 논문 초안의 실행 기반(execution substrate)이자 아티팩트 작업 공간입니다. 또한, Kinsn(kernel operation의 약어)과 그 논문인 BPF-Ext: Safely Extending the eBPF Compilation Pipeline with Native Operations (ACM ATC '26; 위 섹션 참조)에 대한 아티팩트 및 평가 장치(evaluation harness)를 제공합니다.
현재 bpf-bench 인스턴스화는 6개의 프로덕션 eBPF 애플리케이션, 146개의 비교 가능한 BPF 프로그램 측정 항목, 그리고 42개의 마이크로벤치마크 작업을 다루며, 보상 해킹(reward hacking)을 방지하기 위한 정확성 및 무결성 검사가 설계되어 있습니다.
이 실험적인 저장소는 master에서 직접 개발됩니다. 태스크 브랜치를 생성하거나 전환하지 마십시오. 완료된 작업은 origin/master에 반영되어야 합니다.
eBPF 최적화는 유용한 액션이 검증기(verifier) 제약 조건, 커널 버전, 아키텍처, 런타임 상태, 워크로드 동작 및 애플리케이션 의미론에 따라 달라지기 때문에 어렵습니다. 한 프로그램을 개선하는 패스가 다른 프로그램의 성능을 저하시킬 수 있으며, 정적 리라이트 카운트는 속도 향상을 신뢰성 있게 예측하지 못합니다.
bpf-bench는 에이전트가 실제 오라클(real oracle) 하에서 더 나은 최적화 결정을 내릴 수 있는지 평가합니다:
벤치마크 액션 공간은 여러 계층에 걸쳐 있습니다:
bpfopt를 통한 로드 후 바이트코드 정책 선택 (post-load bytecode policy selection through bpfopt)bpfopt와 Kinsn 기반 네이티브 연산은 이 저장소의 액션 백엔드이지만, bpf-bench의 기여는 더 광범위합니다. 이는 실제 verifier, JIT, 애플리케이션 및 워크로드 피드백 하에서의 에이전트형 eBPF 최적화를 위한 벤치마크 및 자동 연구 프레임워크입니다.
프로덕션 코퍼스는 실제 애플리케이션 로더를 사용합니다. 이 프레임워크는 업스트림 바이너리를 단순화된 로더로 대체하지 않으며, 코퍼스 앱을 위해 .bpf.o 파일을 직접 로드하지 않습니다.
지원되는 코퍼스 애플리케이션:
bcc/setotelcol-ebpf-profiler/profilingcilium/agenttetragon/observerkatrantracee/monitor마이크로벤치마크(Microbenchmarks)는 BPF_PROG_TEST_RUN 하에서 순수 바이트코드 실행, 헬퍼(helpers), 맵(maps), 패킷 파싱, 분기 동작 및 아키텍처 민감 로어링(architecture-sensitive lowering)을 격리합니다.
| Project | Code | Current design | Current results | Build and run |
|---|---|---|---|---|
| kprog: native whole-program execution | kprog/ (loader, linker, simulator, Lean) | design | evaluation | project guide |
| ... |
역사적 계획 및 날짜가 지정된 보고서는 archive에 그룹화되어 있습니다. moved-path table은 외부 참조를 위해 이름이 변경된 모든 파일을 매핑합니다.
bpf-benchmark/
├── docs/ebpf27-bpfoptbench/ # bpf-bench paper draft, figures, and analyses
├── runner/ # Make-backed suites, executors, images, libs
...
native-sim은 에이전트 및 이전 경로를 여전히 사용하는 스크립트를 위한 kprog으로의 임시 심볼릭 링크입니다. 새로운 명령어와 참조는 kprog/을 사용합니다.
현재 설계 및 역사적 참고 사항은 위의 프로젝트 테이블에 연결되어 있습니다. 런타임 이미지 레이어링(Runtime image layering) 및 호스트/런타임 경계(host/runtime boundaries)는 runner/containers/README.md에 문서화되어 있습니다.
pip install pyyamldocker 사용sudo -n 사용vng (virtme-ng)PLATFORM=aws를 사용할 때만 AWS 자격 증명 필요# Public submodule만 업데이트합니다. 위에서 "BPF-Ext / Kinsn artifact"를 참조하세요.
git submodule update --init --recursive -- \
vendor/linux-framework llvm-backend/llvm vendor/libbpf vendor/llvmbpf \
...
루트 Makefile이 유일하게 지원되는 벤치마크 진입점입니다. 빌드 종속성, 런타임 이미지, KVM/AWS 디스패치 및 아티팩트 경로의 일관성을 유지하기 위해 make <target>으로 스위트를 실행하세요.
make micro # 로컬 x86 KVM 마이크로 스위트
make micro BENCH="simple bitcount"
make micro SAMPLES=1 WARMUPS=0 INNER_REPEAT=10
...
지원되는 스위트 타겟은 selftest, negative-test, test, micro, corpus, all, 그리고 terminate입니다. 로컬 기본값은 PLATFORM=kvm과 ARCH=x86입니다. AWS 실행 시에는 PLATFORM=aws와 ARCH=x86 또는 ARCH=arm64를 사용합니다.
대상 코퍼스 실행은 corpus/config/macro_apps.yaml에 있는 앱 이름을 사용합니다. 대상 실험이 루트 Makefile을 통해 라우팅되도록 유지하여 앱 시작, 워크로드 설정, 런타임 이미지 선택 및 아티팩트 경로의 일관성을 유지하세요.
# 전체 프로덕션 코퍼스 실행.
make corpus
기본 패스 정책은 corpus/config/benchmark_config.yaml에 있습니다. 대상 패스 실험 역시 루트 Makefile을 통해 진행해야 합니다. 최적화 바이너리를 직접 호출하기보다는 여기에 정의된 스위트 환경 노브(knobs)를 사용하세요.
make corpus SAMPLES=3
현재 지원되는 패밀리는 다음과 같습니다:
kinsn, rotate, cond_select, ccmp, extract, endian_fusion, bulk_memory, prefetchnoop, wide_mem, map_inline, const_prop, dce, bounds_check_merge, skb_load_bytes_specbranch_flipbranch_flip은 실제 사이트별 PMU(Performance Monitoring Unit) 프로파일 입력이 필요하며 기본 러너 정책의 일부가 아닙니다.
기본적으로 작업 디렉터리 tarball은 폐기됩니다. 실제 최적화 실패를 겪는 프로그램에 대한 원시 검증기 로그(raw verifier logs)와 패스별 바이트코드를 검사하려면 보존 기능을 활성화하십시오:
KEEP_WORKDIRS=1 make corpus
tarball은 corpus/results/<run_dir>/details/failure-artifacts/<prog_id>.tar.gz 경로에 작성됩니다.
벤치마크 프레임워크는 원시 측정값만을 기록합니다. result.json에는 run_cnt_delta, run_time_ns_delta, id, name, type, bytes_jited, bytes_xlated와 같은 프로그램별 기준선 및 최적화 후 커널 카운터(kernel counters)가 보존되며, 여기에 워크로드의 stdout/stderr, 생명주기 이벤트, 앱 상태, 오류 문자열 등이 포함됩니다.
원시 애플리케이션 측 워크로드 필드 역시 각 단계별 워크로드 페이로드 아래에 보존될 수 있습니다. 집계(Aggregation), 비율(ratios), 평균(averages), 기하평균(geomeans), 신뢰 구간(confidence intervals), 성공 점수(success scores), 마크다운 성능 요약본(markdown performance rollups)은 벤치마크 러너가 아닌 외부 분석 스크립트에 포함되어야 합니다.
결과는 다음 위치에 작성됩니다:
micro/results/corpus/results/docs/archive/ (원시 JSON 결과 아님)Executor 로그 및 임시 스테이징 상태는 .cache/ 아래에 존재하며, 이 디렉터리들은 벤치마크 결과 루트가 아닙니다.
논문 실험에서는 에이전트를 신뢰할 수 없는 최적화기(untrusted optimizers)로 취급합니다. 에이전트는 워크로드(workloads)를 편집하거나, 실행 시간을 단축시키거나, 실패한 프로그램을 필터링하거나, 애플리케이션 로더(application loaders)를 우회하거나, 결과 파일을 위조하는 방식이 아니라 make 타겟을 통해 벤치마크와 상호작용해야 합니다. 이 프레임워크는 외부 분석이 해당 동작(action)을 수용할지, 정확한지, 더 빠른지, 노이즈가 있는지, 또는 유효하지 않은지 결정할 수 있도록 원시 아티팩트(raw artifacts)를 기록합니다.