Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp88494pxk; Mon, 5 Oct 2020 18:51:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0FZ0F6nkgAXfOdCcFnV+msvd4iHIdvOlWY8vuuktfcm0A1EUeUqdmVZh2L/+DhoZ+TQUR X-Received: by 2002:a17:906:7210:: with SMTP id m16mr2788537ejk.490.1601949117188; Mon, 05 Oct 2020 18:51:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601949117; cv=none; d=google.com; s=arc-20160816; b=mkZU2Vmr12hmnlViAxMkesnQc9zi59SlD9XrPA4JbQmXc7sT5jZ8I93GhNCZuHuhsE qmiMPm6si5SsZDDCIpTOdn69lK9MsZXSeTlCGB0e0l7xM1M7FrqfXjR+jzEJPWYSL9Jq DzYlfcEP+sq28dmlnoSYknpr4IYHlQEGfTeRpyGMf3Os4aPkbRETD4AAoVuVJMskSHdQ /1lq30JiTY/bDdSwot9ZRNWcXJNxyMuAqcjf0dlF8oYh+wA5KdFA2Dh3dCm75GYT+hnX wCZ8e138XdkK+ecmf/8ezzvAVwXHD+z6twzZFA7PBBangZNazRnqJ7C5Ogd+DaVoXCrE RZxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=8tDuc5nM0qZvyfZGwbPBpJwWN3hGhbtERmi3oXX+m+U=; b=055QFLB+mRiW2/7RMLNhTisszErwNtXg4bKp7GXtMU5Kjn20LJswkySsgGZInxwfYA VmIc8CuX6TDPUzoqgX81Ce4aW1iJLNjZNfo8KjaYCHEukGTyaE0jRLSVfOwLRGvz8fO1 PwxhGEcHuYa051lagG/5wjSfN9Ccdd+ZDr3twVzpbLZD9bUfLUYKQLnUE+VJpSh6G8j9 QsdVz0ZxlqN7ytChrg915Pj+6mpYYJ6np0bP5jBOr3TV3B3TpUVFXse8+fByO3FiKL4l BB4PH/v0Gv4wCv+tLinKwzbyHFLHpnCMuOe7Ezz09tTa15wzdjWjpPeZ8M6gemWc/uKu hl5g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k4si1373751edq.423.2020.10.05.18.51.34; Mon, 05 Oct 2020 18:51:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726670AbgJFBsS (ORCPT + 99 others); Mon, 5 Oct 2020 21:48:18 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:50884 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725896AbgJFBsS (ORCPT ); Mon, 5 Oct 2020 21:48:18 -0400 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id E1AFD23746D1A48192D7; Tue, 6 Oct 2020 09:48:14 +0800 (CST) Received: from [10.174.176.61] (10.174.176.61) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.487.0; Tue, 6 Oct 2020 09:48:07 +0800 Subject: Re: [PATCH v12 0/9] support reserving crashkernel above 4G on arm64 kdump To: Bhupesh Sharma , Catalin Marinas References: <20200907134745.25732-1-chenzhou10@huawei.com> <20201005170937.GA14576@gaia> CC: John Donnelly , Will Deacon , James Morse , Thomas Gleixner , "Ingo Molnar" , RuiRui Yang , Baoquan He , Jonathan Corbet , Prabhakar Kushwaha , Simon Horman , Rob Herring , Arnd Bergmann , , linux-arm-kernel , Linux Kernel Mailing List , kexec mailing list , Linux Doc Mailing List , , , , From: chenzhou Message-ID: <8a050973-2eb6-61ed-9172-dd4fd0909f65@huawei.com> Date: Tue, 6 Oct 2020 09:48:06 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.176.61] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bhupesh, On 2020/10/6 1:42, Bhupesh Sharma wrote: > Hi Catalin, Chen, > > On Mon, Oct 5, 2020 at 10:39 PM Catalin Marinas wrote: >> On Sat, Sep 12, 2020 at 06:44:29AM -0500, John Donnelly wrote: >>> On 9/7/20 8:47 AM, Chen Zhou wrote: >>>> Chen Zhou (9): >>>> x86: kdump: move CRASH_ALIGN to 2M >>>> x86: kdump: make the lower bound of crash kernel reservation >>>> consistent >>>> x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions >>>> reserve_crashkernel[_low]() >>>> x86: kdump: move reserve_crashkernel[_low]() into crash_core.c >>>> arm64: kdump: introduce some macroes for crash kernel reservation >>>> arm64: kdump: reimplement crashkernel=X >>>> kdump: add threshold for the required memory >>>> arm64: kdump: add memory for devices by DT property >>>> linux,usable-memory-range >>>> kdump: update Documentation about crashkernel >> [...] >>> I did a brief unit-test on 5.9-rc4. >>> >>> Please add: >>> >>> Tested-by: John Donnelly >> Thanks for testing. >> >>> This activity is over a year old. It needs accepted. >> It's getting there, hopefully in 5.11. There are some minor tweaks to >> address. > I think my earlier email with the test results on this series bounced > off the mailing list server (for some weird reason), but I still see > several issues with this patchset. I will add specific issues in the > review comments for each patch again, but overall, with a crashkernel > size of say 786M, I see the following issue: > > # cat /proc/cmdline > BOOT_IMAGE=(hd7,gpt2)/vmlinuz-5.9.0-rc7+ root=<..snip..> > rd.lvm.lv=<..snip..> crashkernel=786M > > I see two regions of size 786M and 256M reserved in low and high > regions respectively, So we reserve a total of 1042M of memory, which > is an incorrect behaviour: > > # dmesg | grep -i crash > [ 0.000000] Reserving 256MB of low memory at 2816MB for crashkernel > (System low RAM: 768MB) > [ 0.000000] Reserving 786MB of memory at 654158MB for crashkernel > (System RAM: 130816MB) > [ 0.000000] Kernel command line: > BOOT_IMAGE=(hd2,gpt2)/vmlinuz-5.9.0-rc7+ > root=/dev/mapper/rhel_ampere--hr330a--03-root ro > rd.lvm.lv=rhel_ampere-hr330a-03/root > rd.lvm.lv=rhel_ampere-hr330a-03/swap crashkernel=786M cma=1024M > > # cat /proc/iomem | grep -i crash > b0000000-bfffffff : Crash kernel (low) > bfcbe00000-bffcffffff : Crash kernel > > IMO, we should test this feature more before including this in 5.11 Thanks for you test. This behavior is what we what. What is the correct behavior you think? Besides, this feature is been tested by John and PK, and i test for various parameters. We may miss something, any comments are welcome. Thanks, Chen Zhou > > Thanks, > Bhupesh > > . >