Linux Modules
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Alan Maguire <alan.maguire@oracle.com>,
	ast@kernel.org, andrii@kernel.org
Cc: daniel@iogearbox.net, jolsa@kernel.org, ihor.solodrai@linux.dev,
	 yonghong.song@linux.dev, song@kernel.org, qmo@kernel.org,
	martin.lau@linux.dev, 	memxor@gmail.com, emil@etsalapatis.com,
	mcgrof@kernel.org, petr.pavlu@suse.com, 	tj@kernel.org,
	kees@kernel.org, bpf@vger.kernel.org, nathan@kernel.org,
		nsc@kernel.org, arnd@arndb.de, puranjay@kernel.org,
	yatsenko@meta.com, 	atenart@kernel.org, ojeda@kernel.org,
	linux-modules@vger.kernel.org
Subject: Re: [PATCH v2 bpf-next 03/18] libbpf: Support moving permuted BTF types into split BTF
Date: Thu, 10 Sep 2026 02:37:46 -0700	[thread overview]
Message-ID: <98c9c5838b50871b3a138d2104450774268644b3.camel@gmail.com> (raw)
In-Reply-To: <20260901165757.801449-4-alan.maguire@oracle.com>

On Tue, 2026-09-01 at 17:57 +0100, Alan Maguire wrote:
> Extend btf__permute() with an optional transfer mode.  Type-map entries
> marked with BTF_PERMUTE_ID_TRANSFER are removed from the input BTF and
> copied into a newly-created split BTF returned through
> btf_permute_opts.transfer_btf.
> 
> While moving types, remap type IDs for both retained and transferred
> types, preserving split-BTF references to the parent BTF where needed.
> 
> String handling has to be done carefully as we do not want to have
> strings that only exist in the split BTF to impose a cost on the base.
> Copy referenced strings locally first, compact the parent string table
> after the moved types are gone, rebase split-string offsets, and compact
> the split string table.  This leaves strings exclusively needed by moved
> types in the split BTF while retaining shared strings in the parent.
> This will be important later for function names of inline-only functions;
> these should not take up space in base BTF but should have strings in
> inline BTF only.
> 
> This all provides the support needed to place inline-only BTF
> in a separate BTF section, which resolve_btfids will use later.
> 
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> Assisted-by: Codex (GPT-5)
> ---

Hi Alan,

What do you think about an alternative approach to permute and
resolve_btfids changes described below?

Instead of specifying a permute mapping can just rebuild two BTFs from
scratch: base BTF w/o LOC types and .BTF.inline BTF with LOC types only.
This would give strings dedup / compaction for free and would not
require further changes in libbpf.

Concretely, commit [1] (branch [2]) uses the following steps:
- Traverse all types reachable from LOC_PARAM, LOC_PROTO, LOCSEC
  entries and mark them as having LOC color.
- Traverse all types reachable from the remaining types
  and mark them as having MAIN or SHARED colors.
- Create a new base BTF object and copy all MAIN/SHARED types there.
- Create a new .BTF.inline object with base set to the new base BTF
  object, and copy all LOC types there.

This seem to be on par with your current branch with regards to
speed / memory usage:

│ Version                 │ Elapsed, mean ± SEM │ Peak RSS, mean │
├─────────────────────────┼─────────────────────┼────────────────┤
│ Original permute        │ 338.8 ± 8.1 ms      │ 71.20 MiB      │
│ Proposed                │ 284.1 ± 10.2 ms     │ 70.10 MiB      │

But seems a tad simpler in terms of implementation (~ -250 lines of code).

I also changed how LOC-only FUNC objects are identified, by using a
generic type graph traversal utility function (btf_mark_reachable()).
This is a bit less code and opens a possibility to move some more
types to .BTF.inline:

│ Section     │ Before (bytes) │ After          │ Change   │
├─────────────┼────────────────┼────────────────┼──────────┤
│ .BTF        │ 5,207,078      │ 5,047,510      │ −159,568 │
│ .BTF.inline │ 9,867,471      │ 10,027,039     │ +159,568 │

This is the same change, but when allowed to move regular types from
base to .BTF.inline, if those types are not used by base.

[1] https://github.com/eddyz87/bpf/commit/abe515962632ad51f8aa50e44354b88f80bbd606
[2] https://github.com/eddyz87/bpf/tree/resolve-btf-ids-btf-inline
    (tests commit is 100% slop, please ignore it).

Thanks,
Eduard

...

  parent reply	other threads:[~2026-09-10  9:37 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 16:57 [PATCH v2 bpf-next 00/18] Support inline functions in BTF Alan Maguire
2026-09-01 16:57 ` [PATCH v2 bpf-next 01/18] btf: Extend UAPI to support BTF location (inline site) info Alan Maguire
2026-09-01 17:17   ` sashiko-bot
2026-09-01 17:55   ` bot+bpf-ci
2026-09-09 22:26   ` Eduard Zingerman
2026-09-01 16:57 ` [PATCH v2 bpf-next 02/18] libbpf: Add support for BTF kinds LOC[_PARAM|_PROTO|SEC] Alan Maguire
2026-09-01 17:11   ` sashiko-bot
2026-09-09 22:26   ` Eduard Zingerman
2026-09-01 16:57 ` [PATCH v2 bpf-next 03/18] libbpf: Support moving permuted BTF types into split BTF Alan Maguire
2026-09-01 17:15   ` sashiko-bot
2026-09-01 18:14   ` bot+bpf-ci
2026-09-10  9:37   ` Eduard Zingerman [this message]
2026-09-01 16:57 ` [PATCH v2 bpf-next 04/18] selftests/bpf: Test helper support for BTF_KIND_LOC[_PARAM|_PROTO|SEC] Alan Maguire
2026-09-01 17:06   ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 05/18] selftests/bpf: Add LOC_PARAM, LOC_PROTO, LOCSEC to field iter tests Alan Maguire
2026-09-01 16:57 ` [PATCH v2 bpf-next 06/18] selftests/bpf: Add LOC_PARAM, LOC_PROTO, LOCSEC to dedup split tests Alan Maguire
2026-09-01 17:55   ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 07/18] selftests/bpf: BTF distill tests to ensure LOC[_PARAM|_PROTO] add to split BTF Alan Maguire
2026-09-01 17:55   ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 08/18] selftests/bpf: Validate that btf__permute transfer works Alan Maguire
2026-09-01 17:16   ` sashiko-bot
2026-09-01 17:55   ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 09/18] bpftool: Handle multi-split BTF by supporting multiple base BTFs Alan Maguire
2026-09-01 17:13   ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 10/18] bpftool: Document support for multi-split BTF Alan Maguire
2026-09-01 17:12   ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 11/18] bpftool: Add ability to dump LOC_PARAM, LOC_PROTO and LOCSEC Alan Maguire
2026-09-01 17:16   ` sashiko-bot
2026-09-01 17:55   ` bot+bpf-ci
2026-09-07 19:30   ` Alexei Starovoitov
2026-09-01 16:57 ` [PATCH v2 bpf-next 12/18] resolve_btfids: Extract inline BTF Alan Maguire
2026-09-01 17:23   ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 13/18] kbuild: Add support for BTF inline information Alan Maguire
2026-09-01 17:55   ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 14/18] btf: Make vmlinux, module inline info available in /sys/kernel/btf Alan Maguire
2026-09-07 19:34   ` Alexei Starovoitov
2026-09-07 19:50     ` Alan Maguire
2026-09-07 20:00       ` Alexei Starovoitov
2026-09-01 16:57 ` [PATCH v2 bpf-next 15/18] btf: Support CONFIG_DEBUG_INFO_BTF_INLINE=m Alan Maguire
2026-09-01 17:24   ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 16/18] btf: Relocate inline BTF for modules with distilled base BTF Alan Maguire
2026-09-01 17:29   ` sashiko-bot
2026-09-01 17:55   ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 17/18] selftests/bpf: Test BTF sysfs inline representations Alan Maguire
2026-09-01 17:22   ` sashiko-bot
2026-09-01 17:55   ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 18/18] selftests/bpf: Add a test verifying inline information Alan Maguire
2026-09-01 17:28   ` sashiko-bot
2026-09-01 17:55   ` bot+bpf-ci

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=98c9c5838b50871b3a138d2104450774268644b3.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=atenart@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=emil@etsalapatis.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=jolsa@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mcgrof@kernel.org \
    --cc=memxor@gmail.com \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=petr.pavlu@suse.com \
    --cc=puranjay@kernel.org \
    --cc=qmo@kernel.org \
    --cc=song@kernel.org \
    --cc=tj@kernel.org \
    --cc=yatsenko@meta.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