]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
bpf: Prefer packs that won't trigger an IBPB flush on allocation
authorPawan Gupta <pawan.kumar.gupta@linux.intel.com>
Tue, 30 Jun 2026 05:38:54 +0000 (22:38 -0700)
committerDaniel Borkmann <daniel@iogearbox.net>
Wed, 1 Jul 2026 08:33:45 +0000 (10:33 +0200)
commita9b1f19a6a673ba06820898d0f1ad02883ea1639
tree0a8b7398bc9aa2b10005593656ab166ea861d03a
parenta23c1c5396a91680703360d1ee28a44657c503c4
bpf: Prefer packs that won't trigger an IBPB flush on allocation

Currently BPF pack allocator picks the chunks from the first available
pack. While this is okay, it naturally leads to more frequent flushes
when there are multiple packs in the system that weren't used since the
last flush.

As an optimization prefer allocating the new programs from packs that
are unused since last flush. When all packs are dirty, allocation forces
a flush and marks all packs clean.

Below are some future optimizations ideas:

  1. Currently, the "dirty" tracking is only done at the pack-level.
     Flush frequency can further be reduced with chunk-level tracking.
     This requires a new bitmap per-pack to track the dirty state.
  2. IBPB flush is done on all CPUs, even if only a single CPU ran the
     BPF program. On a system with hundreds of CPUs this could be a
     major bottleneck forcing hundreds of IPIs to deliver the flush.
     The solution is to track the CPUs where a BPF program ran, and
     issue IBPB only on those CPUs.
  3. Avoid IBPB when flush is already done at other sources (e.g.
     context switch).

Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
kernel/bpf/core.c