linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	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 14:36:47 +0000	[thread overview]
Message-ID: <20210304143647.GB4731@sirena.org.uk> (raw)
In-Reply-To: <20210304125623.GB20956@willie-the-truck>


[-- Attachment #1.1: Type: text/plain, Size: 1713 bytes --]

On Thu, Mar 04, 2021 at 12:56:24PM +0000, Will Deacon wrote:

> Hmm. Doing this means ./scripts/faddr2line no longer works with the vmlinux,
> which means if somebody forgets to enable DEBUG_INFO they're in for a
> really hard time debugging when something goes wrong.

Assuming they're aware of that script in the first place and try to
translate addreses with it rather just using the function name in the
stack trace, and aren't able to easily rebuild if they decide that it's
something that's useful.  What people do is going to depend a lot on
their use cases.

> Why can't the CI systems just disable DEBUG_INFO themselves instead of
> changing defconfig for everybody?

What's more likely is that they can just increase the amount of space
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.

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-03-04 14:41 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 [this message]
2021-03-04 14:48     ` Will Deacon
2021-03-04 15:18       ` Mark Brown
2021-03-04 16:22         ` Catalin Marinas
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=20210304143647.GB4731@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).