From: Baoquan He <bhe@redhat.com>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: "Geert Uytterhoeven" <geert@linux-m68k.org>,
"Dave Vasilevsky" <dave@vasilevsky.ca>,
linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org,
mpe@ellerman.id.au, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org,
"Reimar Döffinger" <Reimar.Doeffinger@gmx.de>
Subject: Re: [PATCH] crash: Default to CRASH_DUMP=n when support for it is unlikely
Date: Tue, 27 Aug 2024 14:22:28 +0800 [thread overview]
Message-ID: <Zs1wpHxfTcwKr517@MiWiFi-R3L-srv> (raw)
In-Reply-To: <09c29a3c4879d4ce5d8b97fd60d8ba5e38bed979.camel@physik.fu-berlin.de>
On 08/23/24 at 08:16pm, John Paul Adrian Glaubitz wrote:
> Hi Geert,
>
> On Fri, 2024-08-23 at 15:13 +0200, Geert Uytterhoeven wrote:
> > IMHO CRASH_DUMP should just default to n, like most kernel options, as
> > it enables non-trivial extra functionality: the kernel source tree has
> > more than 100 locations that check if CONFIG_CRASH_DUMP is enabled.
>
> I guess we should then revert that part of Baoquan's original patch.
>
> > What is so special about CRASH_DUMP, that it should be enabled by
> > default?
>
> Let's ask Baoquan who made the original change to enable CRASH_DUMP by default.
Sorry for late reply.
It's me who enabled it by default when I clean up the messy Kconfig items
related to kexec/kdump. Before the clean up, CONFIG_CRASH_DUMP only
controlled a very small file including sevearl functions and macro
definitions. But kernel codes took CRASH_DUMP as switch of kdump.
About why it's enabled by default, as Michael has explained in another
thread, distros usualy needs to enable it by default because vmcore
dumping is a very important feature on servers, even guest instances.
Even though kdump codes are enabled to built in, not providing
crashkernel= value won't make vmcore dumping take effect, it won't cost
system resources in that case.
Thanks
Baoquan
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: "Geert Uytterhoeven" <geert@linux-m68k.org>,
"Dave Vasilevsky" <dave@vasilevsky.ca>,
linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org,
mpe@ellerman.id.au, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org,
"Reimar Döffinger" <Reimar.Doeffinger@gmx.de>
Subject: Re: [PATCH] crash: Default to CRASH_DUMP=n when support for it is unlikely
Date: Tue, 27 Aug 2024 14:22:28 +0800 [thread overview]
Message-ID: <Zs1wpHxfTcwKr517@MiWiFi-R3L-srv> (raw)
In-Reply-To: <09c29a3c4879d4ce5d8b97fd60d8ba5e38bed979.camel@physik.fu-berlin.de>
On 08/23/24 at 08:16pm, John Paul Adrian Glaubitz wrote:
> Hi Geert,
>
> On Fri, 2024-08-23 at 15:13 +0200, Geert Uytterhoeven wrote:
> > IMHO CRASH_DUMP should just default to n, like most kernel options, as
> > it enables non-trivial extra functionality: the kernel source tree has
> > more than 100 locations that check if CONFIG_CRASH_DUMP is enabled.
>
> I guess we should then revert that part of Baoquan's original patch.
>
> > What is so special about CRASH_DUMP, that it should be enabled by
> > default?
>
> Let's ask Baoquan who made the original change to enable CRASH_DUMP by default.
Sorry for late reply.
It's me who enabled it by default when I clean up the messy Kconfig items
related to kexec/kdump. Before the clean up, CONFIG_CRASH_DUMP only
controlled a very small file including sevearl functions and macro
definitions. But kernel codes took CRASH_DUMP as switch of kdump.
About why it's enabled by default, as Michael has explained in another
thread, distros usualy needs to enable it by default because vmcore
dumping is a very important feature on servers, even guest instances.
Even though kdump codes are enabled to built in, not providing
crashkernel= value won't make vmcore dumping take effect, it won't cost
system resources in that case.
Thanks
Baoquan
next prev parent reply other threads:[~2024-08-27 6:22 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-23 12:51 [PATCH] crash: Default to CRASH_DUMP=n when support for it is unlikely Dave Vasilevsky
2024-08-23 12:51 ` Dave Vasilevsky
2024-08-23 13:13 ` Geert Uytterhoeven
2024-08-23 13:13 ` Geert Uytterhoeven
2024-08-23 18:16 ` John Paul Adrian Glaubitz
2024-08-23 18:16 ` John Paul Adrian Glaubitz
2024-08-27 6:22 ` Baoquan He [this message]
2024-08-27 6:22 ` Baoquan He
2024-08-27 6:37 ` John Paul Adrian Glaubitz
2024-08-27 6:37 ` John Paul Adrian Glaubitz
2024-08-27 9:01 ` Baoquan He
2024-08-27 9:01 ` Baoquan He
2024-08-26 2:02 ` Michael Ellerman
2024-08-26 2:02 ` Michael Ellerman
2024-08-26 5:38 ` John Paul Adrian Glaubitz
2024-08-26 5:38 ` John Paul Adrian Glaubitz
2024-08-26 6:03 ` Dave Vasilevsky
2024-08-26 6:03 ` Dave Vasilevsky
2024-08-30 3:15 ` Baoquan He
2024-08-30 3:15 ` Baoquan He
2024-08-30 3:37 ` Dave Vasilevsky
2024-08-30 3:37 ` Dave Vasilevsky
2024-08-30 6:30 ` Baoquan He
2024-08-30 6:30 ` Baoquan He
2024-08-30 6:35 ` Baoquan He
2024-08-30 6:35 ` Baoquan He
2024-08-30 7:24 ` Dave Vasilevsky
2024-08-30 7:24 ` Dave Vasilevsky
2024-09-08 19:57 ` Dave Vasilevsky
2024-09-08 19:57 ` Dave Vasilevsky
2024-09-09 2:35 ` Baoquan He
2024-09-09 2:35 ` Baoquan He
2024-09-09 6:40 ` Michael Ellerman
2024-09-09 6:40 ` Michael Ellerman
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=Zs1wpHxfTcwKr517@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=Reimar.Doeffinger@gmx.de \
--cc=dave@vasilevsky.ca \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
/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.