From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E52BAC433F5 for ; Wed, 27 Apr 2022 12:33:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=pECkhgAOsndzzNSEX7hAigBX3jhy7pfkMZQCk/O7p/Q=; b=s7Qk9KMkT2K5Gz 90v8k0xWkgdWETkmCuI3kE5vsseQXp7YCXZGdxYwKtU7NV0boIkdCK6+cusYKHpRRHNrYaDFLgI2c nLfsM31KRNLr5/FS6u2eI11GTZo7Smy7fEa+7DB1kmiAYVD7UgOmMF8bqZKWqZyKy1Qb9WTnbgbk2 M+TqgE3fmtfHFEslHW4yHdFRzCkdV4aEC5dWeFkGNRIE8o28NQHHAhf/SzAiWdCeGuNlDAN0dciji VbwT9q0aScwe3nvscGfoC3dh/sN8jl7fBQ7v8NxMYh4KyOkAaWKwATQ/O/CmpelRaq/90Hz3xi7TM GI+eaIxtR73fGTTHjMOw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1njgqc-001K7S-11; Wed, 27 Apr 2022 12:32:46 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1njgqX-001K6b-FL; Wed, 27 Apr 2022 12:32:43 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0B89B6184A; Wed, 27 Apr 2022 12:32:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19409C385A9; Wed, 27 Apr 2022 12:32:35 +0000 (UTC) Date: Wed, 27 Apr 2022 13:32:32 +0100 From: Catalin Marinas To: "Leizhen (ThunderTown)" Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , linux-kernel@vger.kernel.org, Dave Young , Baoquan He , Vivek Goyal , Eric Biederman , kexec@lists.infradead.org, Will Deacon , linux-arm-kernel@lists.infradead.org, Rob Herring , Frank Rowand , devicetree@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Randy Dunlap , Feng Zhou , Kefeng Wang , Chen Zhou , John Donnelly , Dave Kleikamp Subject: Re: [PATCH v22 5/9] arm64: kdump: Reimplement crashkernel=X Message-ID: References: <20220414115720.1887-1-thunder.leizhen@huawei.com> <20220414115720.1887-6-thunder.leizhen@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220427_053241_630901_DFEA89AD X-CRM114-Status: GOOD ( 42.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Apr 27, 2022 at 02:54:52PM +0800, Leizhen (ThunderTown) wrote: > On 2022/4/27 2:02, Catalin Marinas wrote: > > On Thu, Apr 14, 2022 at 07:57:16PM +0800, Zhen Lei wrote: > >> /* > >> * reserve_crashkernel() - reserves memory for crash kernel > >> * > >> * This function reserves memory area given in "crashkernel=" kernel command > >> * line parameter. The memory reserved is used by dump capture kernel when > >> * primary kernel is crashing. > >> + * > >> + * NOTE: Reservation of crashkernel,low is special since its existence > >> + * is not independent, need rely on the existence of crashkernel,high. > >> + * Here, four cases of crashkernel low memory reservation are summarized: > >> + * 1) crashkernel=Y,low is specified explicitly, the size of crashkernel low > >> + * memory takes Y; > >> + * 2) crashkernel=,low is not given, while crashkernel=,high is specified, > >> + * take the default crashkernel low memory size; > >> + * 3) crashkernel=X is specified, while fallback to get a memory region > >> + * in high memory, take the default crashkernel low memory size; > >> + * 4) crashkernel='invalid value',low is specified, failed the whole > >> + * crashkernel reservation and bail out. > > > > Following the x86 behaviour made sense when we were tried to get that > > code generic. Now that we moved the logic under arch/arm64, we can > > diverge a bit. I lost track of the original (v1/v2) proposal but I > > wonder whether we still need the fallback to high for crashkernel=Y. > > I don't think anyone has raised this demand yet! If it weren't for the > fact that crashkernel=X appeared earlier, it would probably have been > enough for a combination of crashkernel=X,high and crashkernel=Y,low. > > In fact, I also tend not to support "fallback to high for crashkernel=Y". > I took over this from Chen Zhou. In the absence of any objection, I had > to inherit. Now that you've brought it up, I'm happy to delete it. > Supporting this feature complicates the code logic a lot. The point is, > it's not fully backwards compatible yet. For example, someone may want > crashkernel=3G to report failure, but the the new support make it work. BTW, prior to v20, this patch had this line: crashk_low_res.name = "Crash kernel (low)"; I can't find it anymore. Do the kexec tools need to distinguish between low and high or they can cope with multiple "Crash kernel" entries? > > Maybe simpler, no fallbacks: > > > > crashkernel=Y - keep the current behaviour, ignore high,low > > crashkernel=Y,high - allocate above ZONE_DMA > > crashkernel=Y,low - allocate within ZONE_DMA > > > > From your proposal, the difference is that the Y,high option won't > > have any default ZONE_DMA fallback, one would have to explicitly pass > > the Y,low option if needed. > > I agree with you. Now we don't need code generic, so there is no need to > carry the historical burden of other ARCHs. arm64 does not need to delve > into that empirical value(the default size of crash low memory). > > > Just a thought, maybe it makes the code simpler. But I'm open to > > discussion if there are good arguments for the proposed (x86-like) > > behaviour. One argument could be for crashkernel=Y to fall back to high > > if distros don't want to bother with high/low settings. > > I think distros should take precedence over "crashkernel=Y,high". After all, > ZONE_DMA memory is more valuable than high memory. My point is whether an admin configuring the kernel command line needs to know the layout of ZONE_DMA etc. to figure out how much to pass in high and low. The fallbacks in this case have some value but they also complicate the code logic. The 4GB limit does not always make sense either for some platforms (RPi4 has a ZONE_DMA limit of 1GB). I think one could always pass a default command line like: crashkernel=1G,high crashkernel=128M,low without much knowledge of the SoC memory layout. Another option is to only introduce crashkernel=Y,low and, when that is passed, crashkernel=Y can go above arm64_dma_phys_limit. We won't need a 'high' option at all: crashkernel=1G - all within ZONE_DMA crashkernel=1G crashkernel=128M,low - 128M in ZONE_DMA 1G above ZONE_DMA If ZONE_DMA is not present or it extends to the whole RAM, we can ignore the 'low' option. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel