Re: [PATCH bpf-next v2 1/6] resolve_btfids: Deduplicate BTF after btf2btf transformations

On Thu, 2026-08-06 at 13:48 -0700, Ihor Solodrai wrote:
> On 8/6/26 12:05 PM, Eduard Zingerman wrote:
> > On Wed, 2026-08-05 at 16:06 -0700, Ihor Solodrai wrote:
> > > btf2btf() adds new types to the BTF: the KF_IMPLICIT_ARGS transform
> > > synthesizes an _impl FUNC together with its FUNC_PROTO and copies of the
> > > kfunc's decl tags. Nothing deduplicates them afterwards. pahole runs
> > > btf__dedup() on its own output, but that happens before resolve_btfids
> > > sees the BTF, so any type the tool itself creates is emitted as-is, even
> > > when a structurally identical type is already present.
> > > 
> > > Call btf__dedup() at the start of finalize_btf(), so that base
> > > distillation and the by-name sort both operate on the canonical set of
> > > types.
> > > 
> > > Signed-off-by: Ihor Solodrai <[email protected]>
> > > ---
> > 
> > Hi Ihor,
> > 
> > I'm curious if you had a chance to measure how this affects the
> > resolve_btfids running time?
> 
> Yes I did. tl;dr is +30-40% runtime for resolve_btfids:
> 
>   0.18424  +- 0.00174  seconds time elapsed  ( +-  0.94% )   without dedup
>   0.257003 +- 0.000473 seconds time elapsed  ( +-  0.18% )   with dedup
>
> So that's the bad news.
> 
> The good news is that it shouldn't grow, because most of the dedup
> time is just walking BTF. We emit very few types.
> 
> I think it's worth taking a hit, because a non-normalized kernel BTF
> is a petri dish for bugs.

Thx, not that scary then.