From: "Michal Suchánek" <msuchanek@suse.de>
To: Hari Bathini <hbathini@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Jonathan Corbet <corbet@lwn.net>,
Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.cz>,
linuxppc-dev@lists.ozlabs.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 RFT 1/2] powerpc/fadump: reduce memory consumption for capture kernel
Date: Wed, 10 May 2017 16:58:27 +0200 [thread overview]
Message-ID: <20170510165827.5a2e1022@kitsune.suse.cz> (raw)
In-Reply-To: <765ca86f-b6c5-190e-b3a9-91282e199baf@linux.vnet.ibm.com>
On Wed, 3 May 2017 12:43:33 +0530
Hari Bathini <hbathini@linux.vnet.ibm.com> wrote:
> On Tuesday 02 May 2017 09:26 PM, Michal Suchanek wrote:
> > With fadump (dump capture) kernel booting like a regular kernel, it
> > almost needs the same amount of memory to boot as the production
> > kernel, which is unwarranted for a dump capture kernel. But with no
> > option to disable some of the unnecessary subsystems in fadump
> > kernel, that much memory is wasted on fadump, depriving the
> > production kernel of that memory.
> >
> > Introduce kernel parameter 'fadump_append=' that would take regular
> > kernel parameters to be appended when fadump is active.
> > This 'fadump_append=' parameter can be leveraged to pass parameters
> > like nr_cpus=1, cgroup_disable=memory and numa=off, to disable
> > unwarranted resources/subsystems.
> >
> > Also, ensure the log "Firmware-assisted dump is active" is printed
> > early in the boot process to put the subsequent fadump messages in
> > context.
> >
> > Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> > Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
> > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > ---
> > v4:
> > - use space separated arguments instead of comma separated
> > - do not append parameters when fadummp is disabled
> > ---
> > arch/powerpc/kernel/fadump.c | 27 ++++++++++++++++++++++++---
> > 1 file changed, 24 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/fadump.c
> > b/arch/powerpc/kernel/fadump.c index ebf2e9c..e0c728a 100644
> > --- a/arch/powerpc/kernel/fadump.c
> > +++ b/arch/powerpc/kernel/fadump.c
> > @@ -79,8 +79,10 @@ int __init early_init_dt_scan_fw_dump(unsigned
> > long node,
> > * dump data waiting for us.
> > */
> > fdm_active = of_get_flat_dt_prop(node, "ibm,kernel-dump",
> > NULL);
> > - if (fdm_active)
> > + if (fdm_active) {
> > + pr_info("Firmware-assisted dump is active.\n");
> > fw_dump.dump_active = 1;
> > + }
> >
> > /* Get the sizes required to store dump data for the
> > firmware provided
> > * dump sections.
> > @@ -263,8 +265,12 @@ int __init fadump_reserve_mem(void)
> > {
> > unsigned long base, size, memory_boundary;
> >
> > - if (!fw_dump.fadump_enabled)
> > + if (!fw_dump.fadump_enabled) {
> > + if (fw_dump.dump_active)
> > + pr_warn("Firmware-assisted dump was active
> > but kernel"
> > + " booted with fadump disabled!\n");
> > return 0;
> > + }
> >
> > if (!fw_dump.fadump_supported) {
> > printk(KERN_INFO "Firmware-assisted dump is not
> > supported on" @@ -304,7 +310,6 @@ int __init
> > fadump_reserve_mem(void) memory_boundary = memblock_end_of_DRAM();
> >
> > if (fw_dump.dump_active) {
> > - printk(KERN_INFO "Firmware-assisted dump is
> > active.\n"); /*
> > * If last boot has crashed then reserve all the
> > memory
> > * above boot_memory_size so that we don't touch
> > it until @@ -363,6 +368,22 @@ unsigned long __init
> > arch_reserved_kernel_pages(void) return memblock_reserved_size() /
> > PAGE_SIZE; }
> >
> > +/* Look for fadump_append= cmdline option. */
> > +static int __init early_fadump_append_param(char *p)
> > +{
> > + if (!p)
> > + return 1;
> > +
> > + if (fw_dump.fadump_enabled && fw_dump.dump_active) {
> > + pr_info("enforcing additional parameters (%s) passed
> > through "
> > + "'fadump_append=' parameter\n", p);
> > + parse_early_options(p);
>
> While testing this on a system with yaboot bootloader, it seems that
> parsing a parameter with syntax like fadump_append="nr_cpus=1
> numa=off" is not resulting in the intended way..
Since yaboot arguments are quoted you will probably want something like
append = "quiet splash somearg1 somearg2 fadump_append=\"nr_cpus=1
numa=off\""
in yaboot.conf
Looking at the yaboot parser it seems to handle quoting of quotes so
unlike your parser that does not handle quoting of commas it allows
passing arbitrary arguments to both the normal kernel and the fadump
kernel.
Thanks
Michal
next prev parent reply other threads:[~2017-05-10 14:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-02 15:56 Michal Suchanek
2017-05-02 15:56 ` [PATCH v4 RFT 2/2] powerpc/fadump: update documentation about 'fadump_append=' parameter Michal Suchanek
2017-05-02 16:44 ` [PATCH v4 RFT 1/2] powerpc/fadump: reduce memory consumption for capture kernel Hari Bathini
2017-05-03 7:13 ` Hari Bathini
2017-05-03 8:49 ` Hari Bathini
2017-05-10 14:58 ` Michal Suchánek [this message]
2017-05-10 15:10 ` Hari Bathini
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=20170510165827.5a2e1022@kitsune.suse.cz \
--to=msuchanek@suse.de \
--cc=benh@kernel.crashing.org \
--cc=corbet@lwn.net \
--cc=hbathini@linux.vnet.ibm.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhocko@suse.cz \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=vbabka@suse.cz \
/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
all inboxes | Powered by JetHome®