From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752128AbcHHI4T (ORCPT ); Mon, 8 Aug 2016 04:56:19 -0400 Received: from ozlabs.org ([103.22.144.67]:57050 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751280AbcHHI4S (ORCPT ); Mon, 8 Aug 2016 04:56:18 -0400 From: Michael Ellerman To: Hari Bathini , rusty@rustcorp.com.au, ebiederm@xmission.com, vgoyal@redhat.com, linuxppc-dev Cc: Mahesh J Salgaonkar , kexec@lists.infradead.org, lkml , Ananth N Mavinakayanahalli Subject: Re: [RESEND][PATCH v2 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range In-Reply-To: References: <147025270324.29229.8322429758761407397.stgit@hbathini.in.ibm.com> <147025281599.29229.9962999599360876220.stgit@hbathini.in.ibm.com> <87h9b0g953.fsf@concordia.ellerman.id.au> User-Agent: Notmuch/0.21 (https://notmuchmail.org) Date: Mon, 08 Aug 2016 18:56:13 +1000 Message-ID: <87vazbskpe.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hari Bathini 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? 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. Maybe the formula is more complicated than 5% of RAM, but it shouldn't be *that* much more complicated. cheers