[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiG=Bz57AUmbTyZYMKU6C+nZpS8P2=vFf5xAAhBzrPuTQ@mail.gmail.com>
Date: Mon, 20 Apr 2020 09:51:55 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Josh Poimboeuf <jpoimboe@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Masahiro Yamada <masahiroy@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"the arch/x86 maintainers" <x86@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [GIT pull] perf/urgent for 5.7-rc2
On Mon, Apr 20, 2020 at 12:48 AM Ingo Molnar <mingo@...nel.org> wrote:
>
> Fortunately, much of what objtool does against vmlinux.o can be
> parallelized in a rather straightforward fashion I believe, if we build
> with -ffunction-sections.
Well, I was actually thinking about a simpler model.
By "link time" I didn't mean "after final link". Yes, there may be
reasons to do it at that point too (to do any whole-program checks),
but that wasn't what I meant.
I meant literally doing it in the $(LD) and $(AR) phases, when you
still have lots of independent object files that you are just about to
link (or archive - do we even do that any more?) into one.
Then you'd parallelize exactly the same way we do now: one object file
at a time, and with no real change of semantics.
IOW, what I was thinking that instead of doing it as part of a final
step after the CC/AS, we'd do it as a preparatory step before the
LD/AR. Same exact operation, same exact target *.o files, just shifted
in time.
Linus
Powered by blists - more mailing lists