From: Song Liu <song@kernel.org>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
eddyz87@gmail.com, memxor@gmail.com, kernel-team@meta.com,
Song Liu <song@kernel.org>
Subject: [PATCH bpf-next 0/2] bpf: Populate mmap-able array maps lazily
Date: Tue, 21 Jul 2026 23:53:06 -0700 [thread overview]
Message-ID: <20260722065308.4116186-1-song@kernel.org> (raw)
An mmap-able BPF array map (BPF_F_MMAPABLE) has its backing memory
vmalloc'ed up front at map creation time. array_map_mmap() then wires up
the whole mapping eagerly via remap_vmalloc_range(), which calls
vm_insert_page() for every page of the map. This makes every mmap() cost
O(number of pages): an 8MiB map inserts 2048 PTEs on each mmap() and
tears them all down again on munmap(), even when user space only touches
a few pages (or none at all).
This series makes the mapping populate lazily instead, the same way the
arena map already does, turning mmap()/munmap() of an mmap-able array
from O(map size) into O(1). The pages are inserted on demand by a new
map_mmap_fault() callback, dispatched from the shared
bpf_map_default_vmops so that the existing VMA open/close accounting
(VM_MAYWRITE write-active tracking, freeze handling) stays centralized.
Callers that want the pages populated up front can still request that
explicitly with MAP_POPULATE, matching regular file semantics.
Kernel-side access to the map (via the vmalloc address) is unaffected.
Patch 1 implements the lazy faulting. Patch 2 adds an "arraymap-mmap"
benchmark that mmap()s/munmap()s an mmap-able array map from a
configurable number of threads, useful to observe how the cost scales
with the mapping size.
Benchmark results:
Before the patch
nr_threads: 1, map_size: 1048576
arraymap-mmap: throughput: 0.034 +/- 0.000 M ops/s, latency: 29134.211 ns/op
nr_threads: 1, map_size: 8388608
arraymap-mmap: throughput: 0.005 +/- 0.000 M ops/s, latency: 220365.807 ns/op
nr_threads: 1, map_size: 67108864
arraymap-mmap: throughput: 0.001 +/- 0.000 M ops/s, latency: 1749642.119 ns/op
After the patch
nr_threads: 1, map_size: 1048576
arraymap-mmap: throughput: 0.819 +/- 0.002 M ops/s, latency: 1221.476 ns/op
nr_threads: 1, map_size: 8388608
arraymap-mmap: throughput: 0.808 +/- 0.005 M ops/s, latency: 1236.975 ns/op
nr_threads: 1, map_size: 67108864
arraymap-mmap: throughput: 0.738 +/- 0.003 M ops/s, latency: 1355.100 ns/op
Song Liu (2):
bpf: Populate mmap-able array map memory lazily
selftests/bpf: Add mmap/munmap benchmark for array maps
include/linux/bpf.h | 1 +
kernel/bpf/arraymap.c | 40 ++++-
kernel/bpf/syscall.c | 17 ++
tools/testing/selftests/bpf/Makefile | 1 +
tools/testing/selftests/bpf/bench.c | 4 +
.../bpf/benchs/bench_arraymap_mmap.c | 146 ++++++++++++++++++
.../bpf/benchs/run_bench_arraymap_mmap.sh | 15 ++
7 files changed, 221 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/bpf/benchs/bench_arraymap_mmap.c
create mode 100755 tools/testing/selftests/bpf/benchs/run_bench_arraymap_mmap.sh
--
2.53.0-Meta
next reply other threads:[~2026-07-22 6:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 6:53 Song Liu [this message]
2026-07-22 6:53 ` [PATCH bpf-next 1/2] bpf: Populate mmap-able array map memory lazily Song Liu
2026-07-22 7:16 ` sashiko-bot
2026-07-22 6:53 ` [PATCH bpf-next 2/2] selftests/bpf: Add mmap/munmap benchmark for array maps Song Liu
2026-07-22 7:05 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260722065308.4116186-1-song@kernel.org \
--to=song@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@meta.com \
--cc=memxor@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.