eBPF - BPF_MAP_TYPE_PERF_EVENT_ARRAY, BPF_MAP_TYPE_RINGBUF에 대한 다양한 용어들
2가지 맵 타입에 대해 설명했는데요,
eBPF / bpf2go - BPF_PERF_OUTPUT / BPF_MAP_TYPE_PERF_EVENT_ARRAY 사용법
; https://www.sysnet.pe.kr/2/0/13824
eBPF / bpf2go - BPF_RINGBUF_OUTPUT / BPF_MAP_TYPE_RINGBUF 사용법
; https://www.sysnet.pe.kr/2/0/13825
개인적으로 이와 관련한 용어들이 혼란스러웠던 경험이 있어 정리를 해볼까 합니다. ^^ 일단 문서에 나온 내용으로는 명확한데요,
그런데, 정작 설명에 나오는 "BPF_MAP_TYPE_PERF_ARRAY" 유형의 맵은 없습니다. 처음에는 이게 BPF_MAP_TYPE_PERF_EVENT_ARRAY의 오타라고 생각했는데, 검색해 보니 이런 기록이 나옵니다.
// https://lore.kernel.org/lkml/56A1B3D9.20506@huawei.com/t/
bpf__apply_obj_config() is introduced as the core API to apply object
config options to all BPF objects. This patch also does the real work
for setting values for BPF_MAP_TYPE_PERF_ARRAY maps by inserting value
stored in map's private field into the BPF map.
This patch is required because we are not always able to set all
BPF config during parsing. Further patch will set events created
by perf to BPF_MAP_TYPE_PERF_EVENT_ARRAY maps, which is not exist
until perf_evsel__open().
커널 패치와 같은 기술적인 글에서 오타가 있었을 리는 없고... 뭔가 관련 맵이 있는 것도 같지만, 어쨌든 제가 지금까지 정리한 바로는 BPF_MAP_TYPE_PERF_ARRAY == BPF_MAP_TYPE_PERF_EVENT_ARRAY를 의미하는 듯합니다. (혹시 이에 대해 아시는 분은 덧글 부탁드립니다. ^^)
관련해서 공식 문서를 볼까요?
BPF ring buffer
; https://docs.kernel.org/bpf/ringbuf.html
Motivation 부분을 보면, 기존에 구현된 "perf buffer"가 가진 구조적 문제(per-CPU perf ring buffer)를 나열하는데,
- more efficient memory utilization by sharing ring buffer across CPUs;
- preserving ordering of events that happen sequentially in time, even across multiple CPUs (e.g., fork/exec/exit events for a task).
설명으로 봐서는 BPF_MAP_TYPE_PERF_EVENT_ARRAY와 일치합니다. 그리고 저 2가지 문제를 해결하는 좀 더 효율적인 ring buffer가 요구되었다고 나오는데요, 즉,
Map type BPF_MAP_TYPE_RINGBUF 문서의 내용과 합쳐 보면 이렇게 정리가 됩니다.
- "perf buffer" (per-CPU perf ring buffer)를 사용하는 맵 타입: BPF_MAP_TYPE_PERF_EVENT_ARRAY
- "BPF ring buffer" (Single ring buffer shared among all CPUs)를 사용하는 맵 타입: BPF_MAP_TYPE_RINGBUF
다른 문서를 볼까요? 예를 들어, 이전 글에서 실습한
eBPF Tutorial by Example 7: Capturing Process Execution, Output with perf event array 글에서는 perf buffer에 대해 다음과 같은 설명을 하고 있습니다.
eBPF provides two circular buffers for transferring information from eBPF programs to user space controllers. The first one is the perf circular buffer, which has existed since at least kernel v4.15. The second one is the BPF circular buffer introduced later. This article only considers the perf circular buffer.
커널 공식 문서와 연결해 보면 위의 글에서 설명한 2가지 "circular buffer"는 이렇게 정리가 될 것 같습니다.
- "perf circular buffer": 커널 문서의 "perf buffer"
- "BPF circular buffer": 커널 문서의 "BPF ring buffer"
이와 함께 해당 글에서는 첫 번째 유형인 "perf circular buffer"만을 다룬다고 하면서 예제 코드에 "BPF_MAP_TYPE_PERF_EVENT_ARRAY"를 사용하고 있습니다. 용어는 다소 다르지만, 다행히 커널 공식 문서에서 다뤘던 내용과 일치합니다.
아래의 글에는,
OS/linux/BPF/BPF ring buffer.md
; https://github.com/rlaisqls/TIL/blob/main/OS/linux/BPF/BPF%E2%80%85ring%E2%80%85buffer.md
BPF ring buffer
; https://nakryiko.com/posts/bpf-ringbuf/
커널 문서의 perf buffer에 대해 "BPF perfbuf"라고 일컫는데요, 저같은 초보에게는 이것도 좀 혼동이 됩니다. 커널 문서의 설명도 그렇고,
BPF_MAP_TYPE_PERF_EVENT_ARRAY 문서에서도 "on the existing perf-subsystem implementation of ring-buffers"라는 설명으로 볼 때 eBPF에서 BPF_MAP_TYPE_PERF_EVENT_ARRAY 맵을 위해 이미 만들어져 있던 커널 자체의 "perf buffer"를 사용했기 때문에 "BPF perfbuf"라는 용어는 맞지 않고 그냥 "perf buffer"로 쓰는 것이 맞습니다. (아마도 저 문서들은 BPF를 설명하다 보니 자연스럽게 "BPF perfbuf"라고 일컫는 듯합니다.)
그리고 "BPF ring buffer"는 물론 해당 자료 구조가 커널에 의해서 제공되는 것은 동일하지만 전반적으로 커널 내부에서 사용하던 "perf buffer"와는 달리 "BPF ring buffer"는 아예 eBPF 전용으로 새롭게 개발된 것이므로 "BPF" 수식어가 붙는 것이 자연스럽습니다.
어쨌든, "
OS/linux/BPF/BPF ring buffer.md",
BPF ring buffer 문서의 2개 용어는 다음과 같이 정리할 수 있습니다.
- BPF perfbuf(Perfbuf): 커널 문서의 "perf buffer"
- BPF ring buffer(Ringbuf): 커널 문서의 "BPF ring buffer"
정리해 보면, 2가지 유형의 stream map 유형에 대해 공식적인 자료 구조는 커널 문서에서처럼 "perf buffer", "BPF ring buffer"로 통일하는 것이 좋겠다는 생각입니다. ^^
그나저나, 이걸 정리하면서 제가 읽었던 책의 내용이 떠오르는데요,
BPF를 활용한 리눅스 시스템 트레이싱
; https://www.yes24.com/Product/Goods/97681199
170 페이지 "7.6 출력 채널"에서 BPF_PERF_OUTPUT와 BPF_RINGBUF_OUTPUT에 대해 설명하고 있습니다. 책에서는 3가지 출력 채널을 소개하고 있는데,
- 트레이스 파이프(/sys/kernel/debug/trace_pipe)
- Perf 링 버퍼
- 커널 링 버퍼
이 중에서 Perf 링 버퍼는 BPF_PERF_OUTPUT, 커널 링 버퍼는 BPF_RINGBUF_OUTPUT으로 예를 들고 있습니다. 문제는, BPF_RINGBUF_OUTPUT의 경우 이런 식으로 설명하고 있는데요,
남은 출력 포인트는 커널 링 버퍼이며, 흔히 dmesg나 /var/log/message로 확인합니다. 링 버퍼 역시 다른 프로세스와 공유되는 공간이므로 특별한 메시지를 보내는 용도로만 쓰는 것이 좋습니다.
(어차피 /var/log/message는 데몬에 의해 dmesg를 복사하는 식이므로 넘어가고) 왜 여기서 dmesg를 언급하는지 모르겠습니다. 아마도 dmesg가 (단어 그대로 자료 구조의) ring buffer로 동작하는데다 커널 메시지를 수용하기 때문에 저자 나름대로 "커널 링 버퍼"와 BPF_RINGBUF_OUTPUT을 같은 거라고 짐작해 설명한 것 같습니다.
물론, 이것은 사실과 다르며
5. BPF_RINGBUF_OUTPUT 문서에도 나오듯이 오히려 커널 5.8부터라면 더욱 추천하는 유형입니다.
기왕에 언급했으니, 본문과 관련은 없지만 해당 책의 오류 하나를 더 기록으로 남깁니다.
108 페이지 kprobe를 설명하면서 오프셋을 다루는 것에 대해 다음과 같이 설명하고 있는데요,
오프셋 범위는 어디까지나 해당 함수의 범위에서만 유효합니다. 벗어나면 다음과 같이 에러를 만납니다.
예제 6.23 오프셋이 함수의 범위를 벗어나는 경우
$ bpftrace -e 'kprobe:do_sys_open+1 { printf("in here\n"); }'
Attaching 1 probe...
Could not add kprobe into middle of instruction: /usr/lib/debug/boot/vmlinux-5.8.17:do_sys_open+1
이에 대해서는 전에 제가 설명을 했는데요, "해당 함수의 범위"에서 유효한 것이 아니라 "어셈블리 명령어의 시작 위치"에서 유효한 것입니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]