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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C16B2C10F0E for ; Tue, 9 Apr 2019 09:09:25 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 91D6C20883 for ; Tue, 9 Apr 2019 09:09:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Uxo1el0b" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 91D6C20883 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=sT+5qCqXrwMURSVf3eLCc3taorIWJzTVas/liuNa0Lg=; b=Uxo1el0bdAgjE9 h/MWrqu0wo76ZBIdDKULICJGbLsrLEa+nHxoZsUyaPUzeemNXz/EVsL4drtkyu0DGq/+0rymzCryJ wU05iyQGlL5U7ts4hygUcXN0wDg8bm6rAux1WOm3PnLfc71GuR5LsIADhJrtmFzyZ1Z/hz/44EnAi 0/PBD47g7f4jhyyHv53yWWtzuUev/TMz2hlns7hsANsouhzV7BFoUfA/V5Ny7F3V5uYSMb50LhzfM V6D5d8zta2j8/irkshJADnzuNfII8xneM9YZ5pm8X+jaCAioqaCuyumkM81tWLiA/G8yHgHOC0HVY LtbIZzjv6kqEvsbO7QUg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hDmko-0000C7-Rh; Tue, 09 Apr 2019 09:09:18 +0000 Received: from szxga07-in.huawei.com ([45.249.212.35] helo=huawei.com) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hDmjn-0007fB-HL; Tue, 09 Apr 2019 09:08:17 +0000 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 90249B177B81D34F2DA8; Tue, 9 Apr 2019 17:08:09 +0800 (CST) Received: from [127.0.0.1] (10.177.131.64) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.408.0; Tue, 9 Apr 2019 17:08:01 +0800 Subject: Re: [PATCH 0/3] support reserving crashkernel above 4G on arm64 kdump To: Bhupesh Sharma , , , , , , References: <20190403030546.23718-1-chenzhou10@huawei.com> <49012d55-2020-e2ac-1102-59a5f3911a29@redhat.com> From: Chen Zhou Message-ID: <573f2b4b-9a55-d9b2-6de5-0b60eba0b211@huawei.com> Date: Tue, 9 Apr 2019 17:07:59 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <49012d55-2020-e2ac-1102-59a5f3911a29@redhat.com> X-Originating-IP: [10.177.131.64] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190409_020815_992600_56B6315C X-CRM114-Status: GOOD ( 15.56 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-mm@kvack.org, wangkefeng.wang@huawei.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Bhupesh, On 2019/4/9 13:20, Bhupesh Sharma wrote: > Hi Chen, > > Thanks for the patchset. > > Before I review the patches in detail, I have a couple of generic queries. Please see them in-line: > > On 04/03/2019 11:05 AM, Chen Zhou wrote: >> When crashkernel is reserved above 4G in memory, kernel should reserve >> some amount of low memory for swiotlb and some DMA buffers. So there may >> be two crash kernel regions, one is below 4G, the other is above 4G. >> >> Crash dump kernel reads more than one crash kernel regions via a dtb >> property under node /chosen, >> linux,usable-memory-range = . >> >> Besides, we need to modify kexec-tools: >> arm64: support more than one crash kernel regions >> >> Chen Zhou (3): >> arm64: kdump: support reserving crashkernel above 4G >> arm64: kdump: support more than one crash kernel regions >> kdump: update Documentation about crashkernel on arm64 >> >> Documentation/admin-guide/kernel-parameters.txt | 4 +- >> arch/arm64/kernel/setup.c | 3 + >> arch/arm64/mm/init.c | 108 ++++++++++++++++++++---- >> include/linux/memblock.h | 1 + >> mm/memblock.c | 40 +++++++++ >> 5 files changed, 139 insertions(+), 17 deletions(-) > > I am wondering about the use-case for the same. I remember normally fedora-based arm64 systems can do well with a maximum crashkernel size of <=512MB reserved below the 4G boundary. > > So, do you mean that for your use-case (may be a huawei board based setup?), you need: > > - more than 512MB of crashkernel size, or > - you want to split the crashkernel reservation across the 4GB boundary irrespective of the crashkernel size value. > > Thanks, > Bhupesh > > > . > I do this based on below reasons. 1. ARM64 kdump support crashkernel=Y[@X], but now it seems unusable if X is specified above 4GB. 2. There are some cases we couldn't reserve 512MB crashkernel below 4G successfully if there is no continous 512MB system RAM below 4GB. In this case, we need to reserve crashkernel above 4GB. 3. As the memory increases, the bitmap_size in makedumpfile may also increases, we need more memory in kdump capture kernel for kernel dump. Thanks, Chen Zhou _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel