On Thu, Jan 02, 2025 at 03:03:56PM -0500, Steven Rostedt wrote: > Maybe I misunderstood you, if you are not talking about kallsyms, but for > static calls or anything else that references weak functions. > > The reference is not a problem I'm trying to address. The problem with > mcount_loc, is that it is used to create the ftrace_table that is exposed > to user space, and I can't remove entries once they are added. > > To set filter functions you echo names into set_ftrace_filter. If you want > to enabled 5000 filters, that can take over a minute complete. That's > because echoing in names to set_ftrace_filter is an O(n^2) operation. It > has to search every address, call kallsyms on the address then compare it > to every function passed in. If you have 40,000 functions total, and pass > in 5,000 functions, that's 40,000 * 5,000 compares! I'm pretty sure kallsyms has an option to use tree lookups, which would make it ~ 16*5000. > Since tooling is what does add these large number of filters, a shortcut > was added. If a number written into set_ftrace_filter, it doesn't do a > kallsyms lookup, it will enable the nth function in > available_filter_functions. This turns into a O(1) operation. > > libtracefs() will read the available_filter_functions, figure out what to > enable from that, and then write the indexes of all the functions it wants > to enable. This is a much faster operation then echoing the names one at a > time. > > This is where the weak functions becomes an issue. If I just ignore them, > and do not add a place holder in the mcount section. Then the index will be > off, and will break. > > When the issue first came about, I simply ignored the weak functions, but > then my libtracefs self tests started to fail. > > So yes, this is just fixing mcount_loc, but I believe it's the only one > that has a user interface issue. This is quite the insane interface -- but whatever. I still feel strongly you should fix kallsyms so that we can all deal more sanely with the weak crap.
