[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNARPq7Bj+zp7bYyH_uPOyJ9a1-hD-aSq6GDLb8YdqbA-+A@mail.gmail.com>
Date: Fri, 1 Feb 2019 19:09:36 +0900
From: Masahiro Yamada <yamada.masahiro@...ionext.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
Michal Marek <michal.lkml@...kovi.net>
Subject: Re: [PATCH] kbuild: Disable extra debugging info in .s output
On Fri, Feb 1, 2019 at 6:50 PM Borislav Petkov <bp@...en8.de> wrote:
>
> On Fri, Feb 01, 2019 at 12:06:13PM +0900, Masahiro Yamada wrote:
> > This would make the build speed slower
> > because the compiler is invoked to check those flags in every directory.
> >
> > I tested this patch with x86_64_defconfig and GCC 8.2
> > (on ubuntu 18.10 in docker)
> > but I saw no effect of this patch.
>
> Yes, because that's the .s target which is meant to be used to convert
> only a *single* .c file to assembly in order to stare at the resulting
> asm. For example:
>
> make arch/x86/kernel/cpu/common.s
I do know this, and did compare the output
from the *single* target "make arch/x86/kernel/cpu/common.s"
> It is a debugging aid - and a very basic and important one - and is not
> usually used during a normal kernel build. AFAIK.
>
> So we shouldn't worry about any slowdowns here.
Your patch does slowdown the build system extremely.
I provide the result of "perf stat" of the incremental build for you.
Without your patch:
Performance counter stats for 'make -j8' (20 runs):
2.721312445 seconds time elapsed
( +- 1.02% )
With you patch:
Performance counter stats for 'make -j8' (20 runs):
5.038521415 seconds time elapsed
( +- 0.56% )
Why should the normal build affected by the debugging aid?
One more thing, you did not answer my question.
If you are complaining about the DWARF info
enabled by CONFIG_DEBUG_INFO,
I recommend to turn off CONFIG_DEBUG_INFO.
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists