Re: [PATCH bpf-next 2/2] selftests/bpf: Add mmap/munmap benchmark for array maps

[Jiri Olsa <olsajiri@gmail.com>]

On Tue, Jul 28, 2026 at 01:11:49PM -0700, Song Liu wrote:
> On Mon, Jul 27, 2026 at 5:19 PM Song Liu <song@kernel.org> wrote:
> [...]
> > > I think it would make sense to compare cumulative cost of mmap+read-every-page.
> > > I am sure it would also be lower before this change, due to the added context
> > > switches for fault on every page access that would be amortized before this, but
> > > may give a better picture about the difference.
> > >
> > > I do feel like it's a corner case realistically, and after the first fault the
> > > page remains mapped (and users who care about pages being present can go the
> > > route of passing MAP_POPULATE). I am assuming passing that before was a noop, so
> > > it can be added to code in a backwards compatible fashion if someone really
> > > depends on this?
> >
> > Given there is MAP_POPULATE flag, yes, the user can preserve the old
> > behavior with this flag. While this requires users to make changes for
> > this corner case, I think it is still cleaner than adding a BPF map flag
> > for this. If there are no strong objections, I will keep this behavior in v3.
> 
> This turns out to be a little more complicated:
> 
> 1. Bad news: MAP_POPULATE is not a noop for old kernels. The pre
>    fault mechanism still adds some overhead (for almost no gain). For
>    8MiB mmap, MAP_POPULATE addes about 80us (raw data below).
> 
> 2. Good news: We can further improve MAP_POPULATE with a batch
>    pre fault (vm_operations_struct->map_pages). With batch pre fault,
>    mmap then accessing 8MiB is about 34us slower than the best
>    option before the set:
>    (before: no MAP_POPULATE => access all pages: 252us;
>    after: MAP_POPULATE => access all pages: 286us).
> 
> Note that, all the above are worst cases: we need to access all pages
> and fill the page table one way or another. If we don't need to access
> all pages, the change saves a lot (220us => 1.2us) for the mmap.
> 
> Overall, I think this is a net win for most use cases.

sounds good, thanks for all the details

jirka

> 
> Thanks,
> Song
> 
> Raw data:
> 
> All of the following are for 8MiB, access times are in microseconds (us).
> 
> Before:
> no MAP_POPULATE (do not access pages) 220us
> no MAP_POPULATE => access all pages: 252us
> MAP_POPULATE (do not access pages) 304us
> MAP_POPULATE => access all pages: 334us
> 
> After:
> no MAP_POPULATE (do not access pages): 1.2us
> no MAP_POPULATE => access all pages: 543us
> MAP_POPULATE (do not access pages): 262us
> MAP_POPULATE => access all pages: 286us