[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 8 Aug 2016 14:55:59 +0530
From: Hari Bathini <hbathini@...ux.vnet.ibm.com>
To: Michael Ellerman <mpe@...erman.id.au>, rusty@...tcorp.com.au,
ebiederm@...ssion.com, vgoyal@...hat.com,
linuxppc-dev <linuxppc-dev@...abs.org>
Cc: kexec@...ts.infradead.org, lkml <linux-kernel@...r.kernel.org>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>
Subject: Re: [RESEND][PATCH v2 2/2] powerpc/fadump: parse fadump reserve
memory size based on memory range
On Monday 08 August 2016 02:26 PM, Michael Ellerman wrote:
> Hari Bathini <hbathini@...ux.vnet.ibm.com> writes:
>> On Friday 05 August 2016 12:23 AM, Hari Bathini wrote:
>>> On Thursday 04 August 2016 03:15 PM, Michael Ellerman wrote:
>>>> The code already knows how to reserve 5% based on the size of the
>>>> machine's
>>>> memory, as long as no commandline parameter is passed. So why can't we
>>>> just use that logic?
>>> That is the default value reserved but not a good enough value for
>>> every case. It is a bit difficult to come up with a robust formula
>>> that works for every case as new kernel changes could make the
>>> values obsolete. But it won't be all that difficult to find values that
>>> work for different memory ranges for a given kernel version.
>>> Passing that as range based input with "fadump_reserve_mem"
>>> parameter would work for every memory configuration on a
>>> given system, which is what this patch is trying to provide..
>> You want me to add this to the changelog on respin?
Hi Michael,
> I'm not really convinced.
>
> Distros are going to want to specify a fixed set of values for different
> memory sizes, at least that's what I've seen in the past with kdump. So
> I don't see why we can't just do that in the kernel with a formula based
> on memory size, and maybe some other information.
Agreed. Such support would be great but this patch is adding support
for a new syntax for an existing parameter which should still be good
to have?
> Maybe the formula is more complicated than 5% of RAM, but it shouldn't
> be *that* much more complicated.
Depending on what all kernel versions that need support, this can
get ugly? I could be completely wrong though..
Thanks
Hari
> cheers
>
> _______________________________________________
> kexec mailing list
> kexec@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
Powered by blists - more mailing lists