From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Xu Kuohai" <xukuohai@huaweicloud.com>, <bpf@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Cc: "Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Eduard Zingerman" <eddyz87@gmail.com>,
"Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
"Emil Tsalapatis" <emil@etsalapatis.com>,
"Yonghong Song" <yonghong.song@linux.dev>
Subject: Re: [PATCH bpf-next 00/16] Add percpu variable support for bpf arena
Date: Wed, 21 Oct 2026 16:51:01 +0000 [thread overview]
Message-ID: <DMAO6MR4SCMF.2EQPVBE2JH740@gmail.com> (raw)
In-Reply-To: <3f5446dc-7e7a-4f12-89b8-6e590b2ee1b1@huaweicloud.com>
On Wed, Oct 21, 2026 at 06:53 AM Xu Kuohai <xukuohai@huaweicloud.com> wrote:
> 1. The table wastes a pointer (8 bytes) for each non-exist CPUs, as the
> global data is populated at load time by libbpf. On my debian machine,
> the CONFIG_NR_CPUS is 8192, while the machine has just a dozen CPUs, so
> the 64 KB bytes per variable are almost all wasted. An alternative way
> is to allocate the pointers at load time.
Right. It shouldn't be per variable.
'type' can be a struct with all percpu variables of the prog. Then it's
one table per prog, like the kernel has a single
__per_cpu_offset[NR_CPUS].
Allocating the table from the prog at init works too. nr_cpu_ids can
come from user space via rodata.
> 2. For small variables, the page rounding is a big cost as this series. A
> better way is to make percpu copies on the same NUMA node share the same
> page.
With the struct it's one page per cpu for all variables.
I think it's better to share a page between variables of one cpu than
between cpus. Copies of different cpus in one page need cache line
padding to avoid false sharing. The kernel percpu units are page
aligned too.
prev parent reply other threads:[~2026-10-21 16:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 13:22 Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 01/16] libbpf: Collect arena percpu data section Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 02/16] libbpf: Create arena percpu chunk from the arena percpu ELF section Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 03/16] libbpf: Place the percpu chunks in the bpf arena Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 04/16] libbpf: Copy the percpu chunks into " Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 05/16] libbpf: Add the arena percpu chunk attribute to map creation options Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 06/16] libbpf: Relocate arena percpu access instructions Xu Kuohai
2026-10-20 14:29 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 07/16] libbpf: Add arena percpu feature probe Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 08/16] bpf: Extend syscall to accept arena percpu information Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 09/16] bpf: Teach verifier about arena percpu instructions Xu Kuohai
2026-10-20 14:29 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 10/16] bpf, x86: Add support for arena percpu Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 11/16] bpf, arm64: " Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 12/16] libbpf: Introduce arena percpu helpers for user space Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:22 ` [PATCH bpf-next 13/16] bpftool: Emit the arena percpu datasec into skeleton Xu Kuohai
2026-10-20 13:22 ` [PATCH bpf-next 14/16] selftests/bpf: Add test for arena percpu-only object Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 13:23 ` [PATCH bpf-next 15/16] selftests/bpf: Add test for mixed arena percpu object Xu Kuohai
2026-10-20 13:23 ` [PATCH bpf-next 16/16] selftests/bpf: Add test for arena percpu bounds Xu Kuohai
2026-10-20 14:17 ` bot+bpf-ci
2026-10-20 14:47 ` [PATCH bpf-next 00/16] Add percpu variable support for bpf arena Alexei Starovoitov
2026-10-21 13:53 ` Xu Kuohai
2026-10-21 16:51 ` Alexei Starovoitov [this message]
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=DMAO6MR4SCMF.2EQPVBE2JH740@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=memxor@gmail.com \
--cc=xukuohai@huaweicloud.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®