ebpf: remove UNROLL from bounded loops

[florianl]

Inspired by a discussion on Slack started by @gnurizen.

Removing UNROLL from bounded loops started to become possible with torvalds/linux@2589726 in Linux kernels 5.3 and newer.

$ ./bloat-o-meter tracer.ebpf.amd64.orig tracer.ebpf.amd64
function                                             old     new   delta
perf_unwind_python                                  5855    1534   -4321
kprobe_unwind_python                                5855    1534   -4321
perf_unwind_hotspot                                 7607    2017   -5590
kprobe_unwind_hotspot                               7607    2017   -5590
perf_unwind_perl                                    7324    1618   -5706
kprobe_unwind_perl                                  7324    1618   -5706
perf_unwind_php                                     6852     966   -5886
kprobe_unwind_php                                   6852     966   -5886
perf_unwind_dotnet10                                7393    1487   -5906
kprobe_unwind_dotnet10                              7393    1487   -5906
perf_unwind_dotnet                                  7531    1554   -5977
kprobe_unwind_dotnet                                7531    1554   -5977
perf_unwind_v8                                      7906    1674   -6232
kprobe_unwind_v8                                    7906    1674   -6232
perf_unwind_native                                  7810    1531   -6279
kprobe_unwind_native                                7810    1531   -6279
perf_unwind_beam                                    7681    1005   -6676
kprobe_unwind_beam                                  7681    1005   -6676
perf_unwind_ruby                                   14229    1284  -12945
kprobe_unwind_ruby                                 14229    1284  -12945
------------------------------------------------------------------------------
(add/remove: 930/7552 grow/shrink: 0/20 up/down: 0/-131036)Total: -131036 insns

$ ./bloat-o-meter tracer.ebpf.arm64.orig tracer.ebpf.arm64
function                                             old     new   delta
perf_unwind_python                                  5855    1534   -4321
kprobe_unwind_python                                5855    1534   -4321
perf_unwind_hotspot                                 6484    1821   -4663
kprobe_unwind_hotspot                               6484    1821   -4663
perf_unwind_perl                                    7324    1618   -5706
kprobe_unwind_perl                                  7324    1618   -5706
perf_unwind_php                                     6854     978   -5876
kprobe_unwind_php                                   6854     978   -5876
perf_unwind_dotnet10                                7393    1487   -5906
kprobe_unwind_dotnet10                              7393    1487   -5906
perf_unwind_dotnet                                  7531    1554   -5977
kprobe_unwind_dotnet                                7531    1554   -5977
perf_unwind_native                                  7632    1579   -6053
kprobe_unwind_native                                7632    1579   -6053
perf_unwind_v8                                      7970    1684   -6286
kprobe_unwind_v8                                    7970    1684   -6286
perf_unwind_beam                                    7681    1005   -6676
kprobe_unwind_beam                                  7681    1005   -6676
perf_unwind_ruby                                   14229    1284  -12945
kprobe_unwind_ruby                                 14229    1284  -12945
------------------------------------------------------------------------------
(add/remove: 904/7398 grow/shrink: 0/20 up/down: 0/-128818)Total: -128818 insns

[dalehamel]

I think these should be fine, especially considering the integration tests pass. The delta in instruction counts for ruby is phenomenal (and kind of funny haha)

[gnurizen]

Sweet thanks!

[fabled]

All of our loops are bounded. Otherwise they cannot be unrolled. So if going this way I think we can remove the whole UNROLL macro.

[fabled]

Only reason to leave UNROLL is potential performance optimization. If the JIT does not unroll loops, there is a small performance impact by the counter decrement/jump. Perhaps clang already unrolls small loops fully, and bigger loops partly by unrolling a few iterations.

If the JIT/compiler is smart enough the UNROLL can go away. Otherwise it can stay for the selected loops where it has meaningful performance impact. Also in those cases it might be better to insert hand written pragma to specify the number of iterations to unroll.

[fabled]

I suppose the other case is if verifier is unable to verify large loops that are not unrolled. But seems that at least some of the main unwinder loops can be handled.

Would this allow doing a combined iteration count (unwinds per program) for all unwinder?

If yes, does it work for larger numbers? We could increase the number of frames we can unwind for several programs this way.

Another option to investigate would be if we can do one program to unwind all interpreter types to avoid the tail call completely? I suppose doing this could be difficult for the verifier to check.

Just throwing some questions to determine if this helps with other future strategies.

[florianl]

I didn't remove the UNROLL in the two remaining loops (see aea40ff) in the first place, as I thought it would hit the up to 256 rule as defined by #define UNROLL _Pragma("unroll 256"). So I did more experiments and learned, that I was wrong. Therefore I have removed all remains of UNROLL.