Hello Petr,
Thanks for your reply,
> Could you please provide measurements showing how this improves the
> runtime of genksyms and affects the overall kernel build time? Are
>From my build kernel workload, genksyms perf report (record -g -F 99) show:
without patch:
- 7.83% 0.00% genksyms genksyms [.] _start
_start
- __libc_start_main
+ 3.19% yylex
1.81% find_symbol
0.92% is_reserved_word
0.62% free_list
+ 0.56% export_symbol
with patch:(find_symbol() and export_symbol() benifit from this):
- 7.12% 0.00% genksyms genksyms [.] _start
_start
- __libc_start_main
- 3.01% yylex
0.51% malloc
1.65% find_symbol
0.82% is_reserved_word
0.50% free_list
> CRC calculations actually a hot path in genksyms? I don't think it is
> worth complicating the genksyms code with architecture-specific
> optimizations unless there is a clear benefit.
Right.
> Additionally, many distributions already switched to gendwarfksyms last
> year. Unless someone provides a good reason to keep genksyms around,
> I expect it will be deprecated soon and eventually removed. It would be
> more valuable to show whether the same optimization is worthwhile for
> gendwarfksyms.
I see gendwarfksyms use crc32 from <zlib.h>, which from zlib1g-dev and zlib1g.
BRs
Wentao Guan
