From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Guillaume Tucker <guillaume.tucker@collabora.com>,
Kevin Hilman <khilman@baylibre.com>
Subject: Re: [PATCH] arm64: defconfig: Disable DEBUG_INFO
Date: Thu, 4 Mar 2021 16:22:32 +0000 [thread overview]
Message-ID: <20210304162231.GA29547@arm.com> (raw)
In-Reply-To: <20210304151853.GC4731@sirena.org.uk>
On Thu, Mar 04, 2021 at 03:18:53PM +0000, Mark Brown wrote:
> On Thu, Mar 04, 2021 at 02:48:34PM +0000, Will Deacon wrote:
> > On Thu, Mar 04, 2021 at 02:36:47PM +0000, Mark Brown wrote:
> > > they allocate to jobs (that's certainly what KernelCI does). Testing
> > > modified versions of configurations isn't great as half the point of
> > > using the standard configurations is that everyone's working to the same
> > > thing and should in theory be seeing the same stuff, it's easier to name
> > > a standard config than name a standard config and a list of tweaks
> > > applied to it.
>
> > I'd be fine if arm64 build reports came back as "defconfig+DEBUG_INFO=n"
> > and the CI just ran ./scripts/config -d DEBUG_INFO as part of its build
> > step. For runtime testing, however, having the full vmlinux available is
> > really helpful if we need to debug.
I found DEBUG_INFO pretty useful as well and always hated it in the past
when I had to recompile a kernel just to rerun the tests and identify
the source/line of an address (I guess that's why we ended up with this
in defconfig).
> > > This is about picking a sensible default, there's always going to be
> > > cases where someone wants the other value (otherwise it wouldn't be a
> > > config option). The contention is that there's a lot more builds being
> > > slowed down by the extra I/O and disk space being burned than benefit to
> > > people who end up with the debug info turned on and actively use it but
> > > these aren't direct tradeoffs so you can't categorically say something
> > > one way or the other. At the minute defconfig actually results in a
> > > bigger build tree than an allmodconfig for me (6.8G vs 5.2G) which
> > > doesn't seem like what I'd expect.
>
> > I suppose I'm of the opinion that debug info is a waste of time until you
> > need it, and then it's suddenly invaluable. So I'd prefer it to be there by
> > default, as I don't think the extra I/O or disk space is a concern outside
> > of CI. But it would be good to hear what others have to say.
>
> FWIW with laptops the I/O cost tends to make a difference to the
> edit/compile/run time for me, disks are slow and RAM not plentiful.
> Right now I'm sitting at a rather high speced desktop so the build trees
> I got the storage numbers from were all in RAM backed tmpfs and it makes
> very little odds.
How about enabling DEBUG_INFO_REDUCED as a middle ground? For me the
build tree goes from 5.9GB to 2.0GB. I tried faddr2line and still works
as expected (only tried gcc, not sure whether clang honours this
option).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-04 16:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-02 18:58 [PATCH] arm64: defconfig: Disable DEBUG_INFO Mark Brown
2021-03-03 19:24 ` Kevin Hilman
2021-03-04 12:56 ` Will Deacon
2021-03-04 14:36 ` Mark Brown
2021-03-04 14:48 ` Will Deacon
2021-03-04 15:18 ` Mark Brown
2021-03-04 16:22 ` Catalin Marinas [this message]
2021-03-04 16:35 ` Mark Brown
2021-03-04 17:24 ` Kevin Hilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210304162231.GA29547@arm.com \
--to=catalin.marinas@arm.com \
--cc=broonie@kernel.org \
--cc=guillaume.tucker@collabora.com \
--cc=khilman@baylibre.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.