On Wed 2024-09-11 09:20:05, Josh Poimboeuf wrote: > Hi Petr, > > Thank you for trying it out and doing the research to compare it with > kpatch-build. > > On Wed, Sep 11, 2024 at 03:27:27PM +0200, Petr Mladek wrote: > > Without -ffunction-sections -fdata-sections: > > > > $> time make -j8 > > real 0m58.719s > > user 3m25.925s > > sys 0m21.895s > > > > With -ffunction-sections -fdata-sections: > > > > $> time make -j8 > > real 13m28.126s > > user 15m43.944s > > sys 0m29.142s > > That's bad. We should figure out where those bottlenecks are in the > toolchain. I know objtool definitely needs improvements there. It looks that most of the time is spend by the linker "ld". I have be running an incremental build which basically did only the linking: $> time make -j8 real 10m46.911s user 10m46.533s sys 0m13.062s It has spent most of the time on the line: LD vmlinux.o I have been monitoring (very ugly way) the linker process. The last ps output is: $> result=0; while test $result -eq 0 ; do ps faux | grep 16785; result="$?" ; sleep 1 ; done | grep vmlinux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND [...] pmladek 16785 99.6 5.2 869892 853364 pts/5 R+ 16:50 10:03 | \_ ld -m elf_x86_64 -z noexecstack --no-warn-rwx-segments -r -o vmlinux.o --whole-archive vmlinux.a --no-whole-archive --start-group --end-group ^^^^^ It has been running 10:03 minutes. > For kpatch-build, the production kernel is built *without* > -ffunction-sections and -fdata-sections. Then those flags get manually > added to CLAGS by kpatch-build for the comparison builds. It is great that it works this way. It might make sense to use these flags only when klp-build is called. > We rely on ccache to speed up the repeat builds during development. I see. Well, it does not help with the linker :-( > So I think this should be merged once the x86 support is complete, as it > will have users immediately for those who are running on x86 with IBT > and/or LTO. It looks to me that many parts of this patchset do a clean up of the objtool code. It might make sense to merge them even earlier to reduce the size of the patchset. Anyway, I am open to split this into more stages. Big patchsets are always painful. And it seems that there is a big interest to get this into a production ready state. I am not afraid of ending up with a half baked solution. Best Regards, Petr
