BPF List
 help / color / mirror / Atom feed
* [PATCH v2 bpf-next 0/2] bpf: Populate mmap-able array maps lazily
@ 2026-07-22 20:50 Song Liu
  2026-07-22 20:50 ` [PATCH v2 bpf-next 1/2] bpf: Populate mmap-able array map memory lazily Song Liu
  2026-07-22 20:50 ` [PATCH v2 bpf-next 2/2] selftests/bpf: Add mmap/munmap benchmark for array maps Song Liu
  0 siblings, 2 replies; 3+ messages in thread
From: Song Liu @ 2026-07-22 20:50 UTC (permalink / raw)
  To: bpf; +Cc: ast, daniel, andrii, eddyz87, memxor, kernel-team, Song Liu

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, useful to
observe how the cost scales with the mapping size.

Changes in v2:
- Compute the mapping offset with 64-bit arithmetic in array_map_mmap()
  and the fault handler so that a large vm_pgoff cannot overflow the
  bounds check on 32-bit architectures. remap_vmalloc_range(), which is
  no longer used, used to guard against this.
- Benchmark: use the standard -p/--producers option for the thread count
  instead of a custom --nr-threads option. The v1 approach set
  env.producer_cnt from validate(), which runs after the framework has
  already sized the producers array, causing an out-of-bounds write.
(Both issues were pointed out by the Sashiko AI review.)

v1: https://lore.kernel.org/bpf/20260722065308.4116186-1-song@kernel.org/

Benchmark results (single producer thread, ./bench -p1):

Before the patch
  nr_threads: 1, map_size: 1048576
arraymap-mmap: throughput: 0.034 +/- 0.000 M ops/s, latency: 29187.164 ns/op

  nr_threads: 1, map_size: 8388608
arraymap-mmap: throughput: 0.005 +/- 0.000 M ops/s, latency: 220910.150 ns/op

  nr_threads: 1, map_size: 67108864
arraymap-mmap: throughput: 0.001 +/- 0.000 M ops/s, latency: 1765083.440 ns/op

After the patch
  nr_threads: 1, map_size: 1048576
arraymap-mmap: throughput: 0.838 +/- 0.001 M ops/s, latency: 1193.553 ns/op

  nr_threads: 1, map_size: 8388608
arraymap-mmap: throughput: 0.811 +/- 0.002 M ops/s, latency: 1232.728 ns/op

  nr_threads: 1, map_size: 67108864
arraymap-mmap: throughput: 0.747 +/- 0.004 M ops/s, latency: 1339.051 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                         |  43 +++++-
 kernel/bpf/syscall.c                          |  17 +++
 tools/testing/selftests/bpf/Makefile          |   1 +
 tools/testing/selftests/bpf/bench.c           |   4 +
 .../bpf/benchs/bench_arraymap_mmap.c          | 127 ++++++++++++++++++
 .../bpf/benchs/run_bench_arraymap_mmap.sh     |  15 +++
 7 files changed, 204 insertions(+), 4 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-07-22 20:50 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-22 20:50 [PATCH v2 bpf-next 0/2] bpf: Populate mmap-able array maps lazily Song Liu
2026-07-22 20:50 ` [PATCH v2 bpf-next 1/2] bpf: Populate mmap-able array map memory lazily Song Liu
2026-07-22 20:50 ` [PATCH v2 bpf-next 2/2] selftests/bpf: Add mmap/munmap benchmark for array maps Song Liu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox