From: "Michal Suchánek" <msuchanek@suse.de>
To: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 1/2] fadump: reduce memory consumption for capture kernel
Date: Wed, 19 Apr 2017 16:08:26 +0200 [thread overview]
Message-ID: <20170419160826.617d173f@kitsune.suse.cz> (raw)
In-Reply-To: <878tmx6nbw.fsf@concordia.ellerman.id.au>
On Wed, 19 Apr 2017 14:19:47 +1000
Michael Ellerman <mpe@ellerman.id.au> wrote:
> Michal Such=C3=A1nek <msuchanek@suse.de> writes:
> > On Mon, 17 Apr 2017 20:43:02 +0530
> > Hari Bathini <hbathini@linux.vnet.ibm.com> wrote: =20
> >> On Friday 14 April 2017 01:28 AM, Michal Such=C3=A1nek wrote: =20
> >> > more (optional) properties cannot be added? =20
> >>=20
> >> Kernel change seems simple over f/w enhancement.. =20
> >
> > That certainly looks so when you are a kernel developer and can
> > implement the change yourself compared to convincing some firmware
> > developer that this feature makes sense.
> >
> > On the other hand, the proposed kernel-only solution introduces
> > requirement that the maintainer does not like.
> >
> > For the platform as a whole does it make more sense to add a hack to
> > the kernel or does it make sense to enhance the firmware to provide
> > more options for firmware-assisted dump? =20
>=20
> Unfortunately it doesn't really matter, because there is firmware out
> there that implements the current behaviour and will never be updated.
> So we have to work with what's there.
>=20
It's not that with the existing firmware fadump does not work. It just
uses more memory than needed. So if new firmware revision allows more
flexibility it will work for people with updated firmware and people
with outdated firmware will get the current behavior.
The memory saving is only significant for big systems so only people
running those will get significant improvement from the updated
firmware.
Thanks
Michal
next prev parent reply other threads:[~2017-04-19 14:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-07 12:38 [PATCH v2 1/2] fadump: reduce memory consumption for capture kernel Hari Bathini
2017-02-07 12:38 ` [PATCH v2 2/2] fadump: update documentation about introduction of handover area Hari Bathini
2017-04-07 1:54 ` [PATCH v2 1/2] fadump: reduce memory consumption for capture kernel Michael Ellerman
2017-04-07 7:24 ` Hari Bathini
2017-04-07 9:06 ` Hari Bathini
2017-04-07 13:46 ` Michael Ellerman
2017-04-07 17:41 ` Hari Bathini
2017-04-12 20:29 ` Hari Bathini
2017-04-13 19:58 ` Michal Suchánek
2017-04-17 15:13 ` Hari Bathini
2017-04-18 14:18 ` Michal Suchánek
2017-04-19 4:19 ` Michael Ellerman
2017-04-19 14:08 ` Michal Suchánek [this message]
2017-04-20 18:49 ` Hari Bathini
2017-04-24 10:24 ` Michal Suchánek
2017-04-24 12:56 ` Hari Bathini
2017-04-24 14:00 ` Michal Suchánek
2017-04-25 13:13 ` Hari Bathini
2017-04-25 13:29 ` Michal Suchánek
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=20170419160826.617d173f@kitsune.suse.cz \
--to=msuchanek@suse.de \
--cc=linuxppc-dev@lists.ozlabs.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).