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 152E3C433EF for ; Fri, 6 May 2022 17:46:31 +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=9vkfLhsacB5amn7hSLKJ6xP129TIQedSuS27bWvPWwQ=; b=owl2aKTC1W51M8 QX520Khjwa3Syz8FzP4hTeTTr/lofTidusb8hpgNDcy+xJYBNiLdZjR2UOgDt3zgpPnHsMMxFfLO/ EWrHpEG6me5IczBhn2b2sCNhO/eLkSNJWmiHIvDnzPS/7EzOtJeFSAockMvic3TKaYnDa7Pt3B7/+ 5tZdfWxaOwkfjaxjIjPJ4ZfP+M1JCf6ULUcXchThhVDbW/Lg86zBHe2IB8ixGBfq9N4Jqvr3S7Dxk SYbMTUA1D6+WHoJbjZGf9oEwsPLal4BopeUZDZ6kMbIdfB2/VAbnwWcDIg1ju1+l0p6Ccxq+ZlLG6 UffJe3o4pxvMZyB8is+w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nn219-004ZEY-AJ; Fri, 06 May 2022 17:45:27 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nn211-004ZCL-Ov; Fri, 06 May 2022 17:45:21 +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 B43C9620D3; Fri, 6 May 2022 17:45:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22E16C385A8; Fri, 6 May 2022 17:45:13 +0000 (UTC) Date: Fri, 6 May 2022 18:45:10 +0100 From: Catalin Marinas To: Baoquan He Cc: "Leizhen (ThunderTown)" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , linux-kernel@vger.kernel.org, Dave Young , 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 v23 3/6] arm64: kdump: Reimplement crashkernel=X Message-ID: References: <20220505091845.167-1-thunder.leizhen@huawei.com> <20220505091845.167-4-thunder.leizhen@huawei.com> <189f24a8-9e9b-b3e9-7ac5-935433ea575b@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-20220506_104519_926930_63369BB8 X-CRM114-Status: GOOD ( 33.31 ) 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 Fri, May 06, 2022 at 09:16:08PM +0800, Baoquan He wrote: > On 05/06/22 at 11:22am, Leizhen (ThunderTown) wrote: > ...... > > >> @@ -118,8 +159,7 @@ static void __init reserve_crashkernel(void) > > >> if (crash_base) > > >> crash_max = crash_base + crash_size; > > >> > > >> - /* Current arm64 boot protocol requires 2MB alignment */ > > >> - crash_base = memblock_phys_alloc_range(crash_size, SZ_2M, > > >> + crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN, > > >> crash_base, crash_max); > > >> if (!crash_base) { > > >> pr_warn("cannot allocate crashkernel (size:0x%llx)\n", > > > > > > I personally like this but let's see how the other thread goes. I guess > > > > Me too. This fallback complicates code logic more than just a little. > > I'm not sure why someone would rather add fallback than change the bootup > > options to crashkernel=X,[high|low]. Perhaps fallback to high/low is a better > > compatible and extended mode when crashkernel=X fails to reserve memory. And > > the code logic will be much clearer. > > The fallback does complicates code, while it was not made at the > beginning, but added later. The original crahskernel=xM can only reserve > low memory under 896M on x86 to be back compatible with the case in which > normal kernel is x86_64, while kdump kernel could be i386. Then customer > complained why crashkernel=xM can't be put anywhere so that they don't > need to know the details of limited low memory and huge high memory fact > in system. > > The implementation of fallback is truly complicated, but its use is > quite simple. And it makes crashkernel reservation setting simple. > Most of users don't need to know crashkernel=,high, ,low things, unless > the crashkernel region is too big. Nobody wants to take away 1G or more > from low memory for kdump just in case bad thing happens, while normal > kernel itself is seriously impacted by limited low memory. IIUC, that's exactly what happens even on x86, it may take away a significant chunk of the low memory. Let's say we have 1.2GB of 'low' memory (below 4GB) on an arm64 platform. A crashkernel=1G would succeed in a low allocation, pretty much affecting the whole system. It would only fall back to 'high' _if_ you pass something like crashkernel=1.2G so that the low allocation fails. So if I got this right, I find the fall-back from crashkernel=X pretty useless, we shouldn't even try it. It makes more sense if crashkernel=X,high is a hint to attempt a high allocation first with a default low (overridden by a ,low option) or even fall-back to low if there's no memory above 4GB. Could you please have a look at Zhen Lei's latest series without any fall-backs? I'd like to queue that if you are happy with it. We can then look at adding some fall-back options on top. IMO, we should only aim for: crashkernel=X ZONE_DMA allocation, no fall-back crashkernel=X,high hint for high allocation, small default low, fall back to low if alloc fails crashkernel=X,low control the default low allocation, only high is passed With the above, I'd expect admins to just go for crashkernel=X,high on modern hardware with up to date kexec tools and it does the right thing. The crashkernel=X can lead to unexpected results if it eats up all the low memory. Let's say this option is for backwards compatibility only. Thanks. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel