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

Reply via email to