On Tue, Apr 29, 2025 at 1:56 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Tue, Apr 29, 2025 at 12:50 PM Andrii Nakryiko > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > But here you go if you want to play with it ([0]). > > > > And yes, "visited" marks are the solution, but I was thinking that if > > we implement a pre-processing deduplication step as we discussed > > offline, we won't need to do any of this, so didn't want to pursue > > this further. But we can talk about this, of course. So far this > > generality doesn't buy us anything, I got byte-for-byte identical > > bpf_testmod.ko with Alan's and my changes all the same. > > > > [0] https://gist.github.com/anakryiko/fd1c84dcad91141d27d8bd33453521d1 > > I like it. I think it's worth following up with that. > Why do you think max_depth is not enough? > Because of > btf_dedup_identical_types -> > btf_dedup_identical_structs -> > btf_dedup_identical_types > ? > Then pass &max_depth from btf_dedup_is_equiv() ? > yep, that was another option I considered, just have a "global max depth". OK, I'll update my patch and do a bit more benchmarking. I want to see if this doesn't add much to the overall dedup time. Will post something later (probably tomorrow) > The visited mark seems overkill.
