From: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
To: "T.J. Mercier" <tjmercier@google.com>,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
eddyz87@gmail.com, memxor@gmail.com, martin.lau@linux.dev,
song@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org,
emil@etsalapatis.com
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v4 0/2] bpf: htab: Reduce memory use of hash maps
Date: Thu, 17 Sep 2026 17:10:06 +0100 [thread overview]
Message-ID: <15342d9c-d823-427d-9ce8-04cf48c6854b@gmail.com> (raw)
In-Reply-To: <20260812231905.2956588-1-tjmercier@google.com>
On 8/13/26 12:19 AM, T.J. Mercier wrote:
> Memory is expensive and scarce these days. This series reduces the
> memory use of BPF hash maps by eliminating the per-element overheads
> below. This saves up to 50% of per-element memory use for standard and
> PCPU hash maps. The memory use of LRU hash maps is unaffected.
>
> Map Type & Configuration | Old size | New size | Savings
> ------------------------------------|----------|----------|--------
> Standard (key <= 8 B, val <= 8 B) | 64 B | 32 B | 50.0%
> Per-CPU (prealloc) (key <= 8 B) | 64 B | 32 B | 50.0%
> Per-CPU (non-prealloc) (key <= 8 B) | 64 B | 40 B | 37.5%
> LRU (Any key/value size) | - | - | 00.0%
>
T.J. are you still interested landing this? Maybe respin the series?
Alexei was away back when you sent this.
> 1) Unused LRU / PCPU fields in standard and PCPU hash maps (patch 1)
> struct htab_elem is used for all hash map types, and includes fields
> that are not always used (bpf_lru_node, ptr_to_pptr). For standard
> (non-LRU, non-PCPU) hash maps the 24 bytes for the bpf_lru_node (union)
> are entirely overhead and can be eliminated. Non-preallocated PCPU maps
> only need the 8 byte ptr_to_pptr which is currently unioned with the
> unneeded 24 byte bpf_lru_node, so 16 bytes of overhead can be
> eliminated. Preallocated PCPU maps don't need ptr_to_pptr, so 24 bytes
> of overhead can be saved.
>
> 2) Hash caching for small keys (patch 2)
> For hash maps with small key sizes (<= word size), comparing keys only
> requires a single instruction. Currently the 4 byte hash value (8 byte
> aligned and padded) is used for this, but offers no performance
> advantage in this case and can be eliminated.
>
> The implementation splits htab_elem into dedicated structures for the
> different map types (htab_elem_lru, htab_elem_pcpu, htab_elem) which
> share a common initial sequence (struct htab_node), but contain
> additional map-type specific fields where necessary. This means the
> placement of the key for each element varies with the map type, and
> key_offset is added to bpf_htab for this purpose.
>
> While using key_offset and conditional hash checks adds new pointer
> dereferences and branching during element traversal,
> run_bench_htab_mem.sh shows no significant performance regression across
> 10 runs on my 3995WX.
>
> Benchmark (all in kops/sec) | Avg. Before | StDev | Avg. After | StDev
> -----------------------------|-------------|-------|------------|------
> prealloc overwrite | 115.11 | 4.10 | 115.45 | 5.24
> prealloc batch_add_batch_del | 127.14 | 4.32 | 127.06 | 2.32
> prealloc add_del_on_diff_cpu | 23.22 | 0.93 | 22.91 | 1.60
> normal overwrite | 78.52 | 3.05 | 80.40 | 3.25
> normal batch_add_batch_del | 45.37 | 0.69 | 47.71 | 0.66
> normal add_del_on_diff_cpu | 12.02 | 0.73 | 12.48 | 0.70
>
> ---
> Changes in v4:
> Removed inline from new functions per BPF CI (netdev/source_inline).
>
> From Mykyta Yatsenko:
> Factor out duplicate lookup_elem code into __lookup_elem_raw.
> Use offsetof instead of sizeof for key_offset assignments in
> htab_map_alloc (patch 1).
> Eliminate branching and htab_elem casting in htab_elem_hash /
> htab_elem_set_hash.
>
> Changes in v3:
> From Sashiko on torn reads/writes:
> Use a local unsigned long and READ_ONCE / WRITE_ONCE instead of memcmp /
> memcpy for atomic key comparisons for hashless elements.
>
> Changes in v2:
> Make maximum key_size for !has_hash depend on word size for atomicity
> on 32-bit.
>
> From Mykyta Yatsenko:
> Put the htab_elem* common initial sequence in its own struct (htab_node)
> and reuse it across all element types that share it. Eliminate
> associated BUILD_BUG_ON additions.
> Replace both the hash and key fields with data[].
> Store has_hash in struct bpf_htab, and avoid per-element reads of it.# Please edit the description for the branch
>
> T.J. Mercier (2):
> bpf: htab: Split htab_elem_lru and htab_elem_pcpu off of htab_elem
> bpf: htab: Reduce elem_size by 8 bytes for small key sizes
>
> kernel/bpf/hashtab.c | 418 ++++++++++++------
> kernel/bpf/map_in_map.c | 13 +
> kernel/bpf/map_in_map.h | 2 +
> .../selftests/bpf/progs/map_ptr_kern.c | 2 +-
> 4 files changed, 289 insertions(+), 146 deletions(-)
>
>
> base-commit: cfce77b63375dac81d53f2f85593c548415206b7
next prev parent reply other threads:[~2026-09-17 16:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 23:19 T.J. Mercier
2026-08-12 23:19 ` [PATCH bpf-next v4 1/2] bpf: htab: Split htab_elem_lru and htab_elem_pcpu off of htab_elem T.J. Mercier
2026-08-13 0:22 ` bot+bpf-ci
2026-08-12 23:19 ` [PATCH bpf-next v4 2/2] bpf: htab: Reduce elem_size by 8 bytes for small key sizes T.J. Mercier
2026-08-13 0:22 ` bot+bpf-ci
2026-08-13 16:49 ` T.J. Mercier
2026-09-17 16:10 ` Mykyta Yatsenko [this message]
2026-09-17 16:30 ` [PATCH bpf-next v4 0/2] bpf: htab: Reduce memory use of hash maps T.J. Mercier
2026-09-17 21:21 ` Andrii Nakryiko
2026-09-18 0:31 ` T.J. Mercier
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=15342d9c-d823-427d-9ce8-04cf48c6854b@gmail.com \
--to=mykyta.yatsenko5@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=song@kernel.org \
--cc=tjmercier@google.com \
--cc=yonghong.song@linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®