From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5038C26980F for ; Mon, 21 Sep 2026 00:22:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.200 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789950138; cv=none; b=XPFPXH4wAqGaVfydNF6uVGMfQ2N2EsymPoH2zURh4TDxKZzTOwIkicJe9hEnEVhGPyQWlk2Q42ei1otgMtfCRJNPx6p/qQ9k1Yl1Zad55idBzc2ABnXWvoRZ07obReCqpABanHX8D7MxkBIO7AC6ZjLzuP8Y7zOhGT2ClSajb5Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789950138; c=relaxed/simple; bh=QMpJAHW6iJKz7zydVmvohHjsWjgI3mZnZNwE9Q/LXqE=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=Vk9c6/Y/t89he7228U1s1yrj/2NYdEtkQ2R8jvDfcKlTD0W2iPMLXfBmR8/YnON+RqX8538eMWACT6Qvoqe/NI+yOoOfgvF6wLhH5T+306VdyLyWwcZd3DK+8iR1wyLDURmjgybQN/c6MYi72ZSZF/NXQ3Oni9JooiHvlfF0TaI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--tjmercier.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=U8SnrT/9; arc=none smtp.client-ip=209.85.214.200 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--tjmercier.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="U8SnrT/9" Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2db8e9fe9c7so35309925ad.0 for ; Sun, 20 Sep 2026 17:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1789950137; x=1790554937; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:mime-version:date:from:to:cc:subject:date:message-id :reply-to:content-type; bh=MFnE1lNKWOxXaJ6iiEL1DLT3dpDyZMEN/2e4s9+fthI=; b=U8SnrT/9JoivbVKHrh026ol9folWHS/WqoT8i0rTfazY+sggMb0QqJ2kRNpaGM6Dcg +RrYz3dTXW1wtabmm7W06yZxOc2rVSB3OpQwr8LcZYmLPw05wT1OEmJowQEUKiNdBHFS QBJAalapCalcrEuC9JEY636ssuubTTc1FxwRmhT82IkpEwgcUtvXqEUV82EVoB6QaLvL ZBw6cbYtutJ5nkeMc27x22BWdRrsXGnlbCOFimr0YFI3f/baQBAA/qxOR9K+sA0B1ZJa zj1ogYXFuXbZbstDK6GVu3npNi2/bxx/QSgdKAjLJEtzYDhGATWh+yDtRPC+vqudAX0B STpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789950137; x=1790554937; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:mime-version:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=MFnE1lNKWOxXaJ6iiEL1DLT3dpDyZMEN/2e4s9+fthI=; b=21aYuZHwVTW0cPue/NTINEaQgFfbo6ILBwQfqsJRfLL5rwBlUJM95HoCARxBypp1E0 uHMmCvUjYaxrxxKLFWIlQupJKy1z+4ewBAHw3MF1iKAFuUudktQ1L/ePL7cTTEz9Cie4 /iSNdstyrKtx3HA/FlnIXWArlVM5Br11bt1Ue/rXbAImG52/mG66Y2xfkvZSsOak6hrZ Tjc2rCAoTua0x8y4v0Rt3cxAlfaAGpdY6XHnGSVJ0F4jsCT/tez3KqsGQbR+1oVM2+L9 wuhJEQXRcVA2718o3Y+YlcrwBZZgBBxi3VDuUlSyhRqmy64QcqEPMaMg2k9PHaXZDB8f U7IQ== X-Forwarded-Encrypted: i=1; AKwUvBylUWW7UcS2+PCAhcmsOaHHcFmiJ+c8Z1xVvAnji8k87RGsNKh/+f1lFVWDrKguiI1aJikp+OtQiHxW/Y4=@vger.kernel.org X-Gm-Message-State: AFuF++kMs8eLEDK69Npxv4AkLVlDi+QbpKBuCYMripdfaKRFTvzwi1Tk CXXiyXm68zvXGQwwp9aga2OsCg2J+MgSwzsyXQTKkkIHYsLLsDYneP6BwQQY/lHn7nTpkVMkmYH 9C2heaPklrX3uNVLMnw== X-Received: from plcp9.prod.google.com ([2002:a17:902:e349:b0:2df:4244:c983]) (user=tjmercier job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:8c6:b0:2df:42de:f71 with SMTP id d9443c01a7336-2df42de1624mr31028995ad.19.1789950136472; Sun, 20 Sep 2026 17:22:16 -0700 (PDT) Date: Sun, 20 Sep 2026 17:22:02 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.55.0.1082.g2b9226bbc0-goog Message-ID: <20260921002206.184660-1-tjmercier@google.com> Subject: [PATCH bpf-next v5 0/2] bpf: htab: Reduce memory use of hash maps From: "T.J. Mercier" To: 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, ihor.solodrai@linux.dev, mykyta.yatsenko5@gmail.com Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org, "T.J. Mercier" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =E2=89=A4 8 B, val =E2=89=A4 8 B) | 64 B | 32 B | = 50.0% Per-CPU (prealloc) (key =E2=89=A4 8 B) | 64 B | 32 B | 50.0% Per-CPU (non-prealloc) (key =E2=89=A4 8 B) | 64 B | 40 B | 37.5% LRU (Any key/value size) | - | - | 00.0% 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 (=E2=89=A4 word size), comparing keys on= ly 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, htab_elem_pcpu, htab_elem_lru with hashed and unhashed variants) so that the map-type specific fields exist only in structures where they are necessary. In all hashed variants, the hash is always at a -8 byte offset from the start of htab_elem. The elem_offset map field supports the different sized element headers, and allows dynamic offsets to be kept out of the hot lookup path. It is used primarliy for allocation / free, and indexing preallocated elements. run_bench_htab_mem.sh shows the following changes across 10 runs on my 3995WX. Benchmark (all in kops/sec) | Avg. Before | Avg. After | Delta -----------------------------|---------------|--------------|-------- prealloc overwrite | 116.26 =C2=B1 4.3 | 118.81 =C2=B1 4.2 | +2.= 19% prealloc batch_add_batch_del | 128.43 =C2=B1 3.6 | 128.89 =C2=B1 2.9 | +0.= 35% prealloc add_del_on_diff_cpu | 22.91 =C2=B1 0.69 | 22.44 =C2=B1 0.62 | -2.= 07% normal overwrite | 72.43 =C2=B1 3.13 | 81.06 =C2=B1 1.49 | +11= .9% normal batch_add_batch_del | 45.20 =C2=B1 0.78 | 50.09 =C2=B1 0.56 | +10= .8% normal add_del_on_diff_cpu | 12.02 =C2=B1 0.24 | 12.80 =C2=B1 0.18 | +6.= 49% --- Changes in v5: Rebase on top of bpf-next/for-next Update elem_size check in map_ptr_kern selftest to 40 in first patch (Sashiko) Place hash at constant compile-time offset before htab_elem, to allow removal of key_offset. (Andrii Nakryiko) This avoids dynamic htab->key_offset load and pointer arithmetic. The struct declarations got reworked to implement this, and htab_node was dropped. All map_in_map changes became unnecessary and were dropped. Fix key update before pptr, value initialization for recycled elements and lockless readers. (Sashiko finding on internal run) Read / write memory barriers and READ_ONCE() / WRITE_ONCE() were added for this. Combine rhtab_mem_dtor() and htab_mem_dtor() implementations. Fixed the KMALLOC_MAX_SIZE overflow check since sizeof(struct htab_elem) shrinks in both patches. 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. 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 | 351 +++++++++++++----- .../selftests/bpf/progs/map_ptr_kern.c | 2 +- 2 files changed, 255 insertions(+), 98 deletions(-) base-commit: b99f71407ce529ba01a9392f477522d2e76c6613 --=20 2.55.0.1082.g2b9226bbc0-goog