Message ID | 20221102084921.1615-1-thunder.leizhen@huawei.com (mailing list archive) |
---|---|
Headers | show |
Series | kallsyms: Optimizes the performance of lookup symbols | expand |
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
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 ? Luis
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 > . >