Re: [PATCH RFC bpf-next 0/4] bpf: replace min/max fields with struct cnum{32,64}

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2026-04-21 at 09:10 -0700, Alexei Starovoitov wrote:
> On Tue Apr 21, 2026 at 3:28 AM PDT, Eduard Zingerman wrote:
> > 
> > Debug metrics
> > =============
> > 
> > To understand the practical impact of the precision trade-offs,
> > two debug counters were added (here [3]):
> > 
> > - isec_overapprox: counts how many times cnum_intersect() in
> >   conditional branch refinement had to collapse two disjoint arcs into
> >   one, losing precision that the signed/unsigned pair could represent.
> > 
> > - crossing_poles: counts how many times an ALU operation produces a
> >   cnum that crosses both the unsigned (0/U_MAX) and signed
> >   (S_MAX/S_MIN) boundaries simultaneously. Such cnums cannot be
> >   represented as a pair of signed and unsigned ranges.
> > 
> > Across 6683 programs:
> > - crossing_poles fires 551K times for 21% of programs.
> > - isec_overapprox fires 119K times for 12% of programs,
> 
> so cnums win 551k times and lose 119k ?

Yes

> >   most programs have only 1-5 hits. The bulk comes from a few large
> >   sched_ext and profiling programs.
> 
> and most losses are in sched_ext, yet overall it's a win:
> 
>  scx_rusty.bpf.o  rusty_enqueue         39842      22053  -17789 (-44.65%)
>  scx_rusty.bpf.o  rusty_stopping        37738      19949  -17789 (-47.14%)
>  scx_wd40.bpf.o   wd40_stopping         37729      19880  -17849 (-47.31%)

Yes

> > - 801 programs have crossing_poles > 0 with isec_overapprox = 0.
> > - 202 programs have isec_overapprox > 0 with crossing_poles = 0.
> 
> similar wins vs losses story ?

Yes, is similar to the ratio for win/loss.
But it was counted when general win/loss summary was computed.
I guess, the main takeaway is that crossing_poles happens more often
than isec_overapprox and it can lead to some overall performance wins.
I thought about forking additional states if an over-approximation
is about to happen, but didn't to the experiment.

> 
> I think even without wins we have to adopt cnum-s mainly for memory
> savings. Once we move to model where do_check_insn() is a transfer
> function the memory savings will become more important.