From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752161AbcHHJ1H (ORCPT ); Mon, 8 Aug 2016 05:27:07 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:36741 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751979AbcHHJ0J (ORCPT ); Mon, 8 Aug 2016 05:26:09 -0400 X-IBM-Helo: d23dlp02.au.ibm.com X-IBM-MailFrom: hbathini@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Subject: Re: [RESEND][PATCH v2 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range To: Michael Ellerman , rusty@rustcorp.com.au, ebiederm@xmission.com, vgoyal@redhat.com, linuxppc-dev References: <147025270324.29229.8322429758761407397.stgit@hbathini.in.ibm.com> <147025281599.29229.9962999599360876220.stgit@hbathini.in.ibm.com> <87h9b0g953.fsf@concordia.ellerman.id.au> <87vazbskpe.fsf@concordia.ellerman.id.au> Cc: kexec@lists.infradead.org, lkml , Ananth N Mavinakayanahalli From: Hari Bathini Date: Mon, 8 Aug 2016 14:55:59 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <87vazbskpe.fsf@concordia.ellerman.id.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16080809-0004-0000-0000-00000183C49A X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16080809-0005-0000-0000-0000086B9FBD Message-Id: <94029a02-4357-ed77-5fb9-4ca3271e43ea@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-08_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608080111 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 08 August 2016 02:26 PM, Michael Ellerman wrote: > 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? 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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec >