All of lore.kernel.org
 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 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.