On 2022/11/13 10:55, Luis Chamberlain wrote: > On Sat, Nov 12, 2022 at 06:44:26PM -0800, Luis Chamberlain wrote: >> On Wed, Nov 02, 2022 at 04:49:12PM +0800, Zhen Lei wrote: >>> v7 --> v8: >>> Sort the symbols by name and implement kallsyms_lookup_name() using a binary >>> search. The performance is more than 20 times higher than that of v7. Of course, >>> the memory overhead is also extended to (3 * kallsyms_num_syms) bytes. Discard >>> all implementations of compression and then comparison in v7. >>> >>> In addition, all sparse warnings about kallsyms_selftest.c are cleared. >> >> Awesome work, I can't find a single thing I hate about this, but my >> biggest conern is the lack of testing so I'm going to merge this to > > Sorry finished the email too fast, I just wanted to add Nick to the > thread as his work does tons of changes on scripts/kallsyms.c. > > I was saying -- I'm just concern with the lack of testing so I have merged > this to modules-next and see what explodes over the next few weeks. > I'm also happy to drop this from modules-next and have it go through > the livepatching tree instead, but given Nick's work is dedicated > towards modules and it also touches on scripts/kallsyms.c a lot, to > avoid conflicts it felt best to merge that to modules for now in case > his changes get merged during the next merge window. > > Let me know what folks prefer. > > Obviously, if testing blows up we can drop the series. > > Zhen, wouldn't ftrace benefit from the same > s/kallsyms_on_each_symbol/kallsyms_on_each_match_symbol ? ftrace uses regular matching, so it cannot be replaced. > > Luis > . > -- Regards, Zhen Lei