Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp6748081iob; Wed, 11 May 2022 04:40:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJycrlpOq/QSa7MmvUcsm7TXMDaZBVwCwUieaIyESC6kWu+BHCW1NhKY6jsqgKxUVVtpAAnv X-Received: by 2002:a17:906:5d11:b0:6f5:942e:bc60 with SMTP id g17-20020a1709065d1100b006f5942ebc60mr22036360ejt.254.1652269228560; Wed, 11 May 2022 04:40:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652269228; cv=none; d=google.com; s=arc-20160816; b=MvOTnbmd0b3dtnkQc7LV4ams6mnUsEcVCjQC/nMqpG69wVMKX/c29shFvMjUb+Ee5r ayvhBhu+BYm+wj1AH9T0nvvS3y6VbelsPU75jfLnPaHRN0sO1htlsgYQBdhlZe4G8YbG 2Mdf+iaUetnXxGXbV5wN7/+Ivpyn5wesXP+ZUVCivuXkdff5bn8CWpAbTWZMj1FneF0J w2NsMLVWWN6luerTjUtfYNKfVv6IFBp0NjtNFX1TdFWaP+SCRe6bGVxPyjgjEhxKZg1J qn3MyDY4lA8K4ru/AhkaMn4VihGv59tF/oKxNlXog/plzx9gnDRW6idTfKhfyIOObEPr 81Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=PE8yCPPeI4gW8GY6iuX2dCeIklw1xJGTFn1tAPHKtoY=; b=fFCKGumX+Kva0k61XkZ9JMUFbRUb1PS209X/r8r04IOL7YnbwaCQKiFxSWYlgS4yrN Sa2HTOcmSJ0/s+0LQt9uwNX90N8Mox3ERjaaU+kgAicM7f3+AFqt554BylC2zdQoxUBM Hty/zTkkbma66SqN5OrBOmFwggVUzWYrszI7Gii6XBwh7DDIKxP11FQGDGKJET8wMt/h URTo0ic9LHfleVJ4s5CQHjNu9YuSAH0UcnYmJuPeP2MqeHhp/zK+2tmwao7XaK/wG0Dn Frb1modduuTUPNS/AQqNV33YjkUYP+y5hpVTETBGletL9qvdiCo0k16GbnNFQ6/6rjhC Vp5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q1-20020a50cc81000000b00425ee4958fasi1811453edi.67.2022.05.11.04.40.01; Wed, 11 May 2022 04:40:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235818AbiEKJwG (ORCPT + 99 others); Wed, 11 May 2022 05:52:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46866 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238629AbiEKJvP (ORCPT ); Wed, 11 May 2022 05:51:15 -0400 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9191031350; Wed, 11 May 2022 02:50:54 -0700 (PDT) Received: from dggpemm500022.china.huawei.com (unknown [172.30.72.53]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4KyqmF1nTWzCsdt; Wed, 11 May 2022 17:46:05 +0800 (CST) Received: from dggpemm500006.china.huawei.com (7.185.36.236) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 11 May 2022 17:50:52 +0800 Received: from [10.174.178.55] (10.174.178.55) by dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 11 May 2022 17:50:51 +0800 Subject: Re: [PATCH] arm64: kdump: Do not allocate crash low memory if not needed To: Baoquan He CC: Dave Young , Vivek Goyal , , , Catalin Marinas , Will Deacon , , Jonathan Corbet , , "Eric W . Biederman" , Randy Dunlap , Feng Zhou , Kefeng Wang , Chen Zhou , John Donnelly , "Dave Kleikamp" References: <20220511032033.426-1-thunder.leizhen@huawei.com> From: "Leizhen (ThunderTown)" Message-ID: <8922e61e-ab7c-6e48-ad8c-57b75156a0f2@huawei.com> Date: Wed, 11 May 2022 17:50:51 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.55] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500006.china.huawei.com (7.185.36.236) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/5/11 17:06, Baoquan He wrote: > On 05/11/22 at 11:20am, Zhen Lei wrote: >> When "crashkernel=X,high" is specified, the specified "crashkernel=Y,low" >> memory is not required in the following corner cases: >> 1. If both CONFIG_ZONE_DMA and CONFIG_ZONE_DMA32 are disabled, it means >> that the devices can access any memory. >> 2. If the system memory is small, the crash high memory may be allocated >> from the DMA zones. If that happens, there's no need to allocate >> another crash low memory because there's already one. >> >> Add condition '(crash_base >= CRASH_ADDR_LOW_MAX)' to determine whether >> the 'high' memory is allocated above DMA zones. Note: when both >> CONFIG_ZONE_DMA and CONFIG_ZONE_DMA32 are disabled, the entire physical >> memory is DMA accessible, CRASH_ADDR_LOW_MAX equals 'PHYS_MASK + 1'. >> >> Signed-off-by: Zhen Lei >> --- >> Documentation/admin-guide/kernel-parameters.txt | 5 +++-- >> arch/arm64/mm/init.c | 3 ++- >> 2 files changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt >> index f6ff55840751a78..1b543c3109f4851 100644 >> --- a/Documentation/admin-guide/kernel-parameters.txt >> +++ b/Documentation/admin-guide/kernel-parameters.txt >> @@ -823,7 +823,7 @@ >> low memory is needed to make sure DMA buffers for 32-bit >> devices won't run out. Kernel would try to allocate >> at least 256M below 4G automatically. >> - This one let user to specify own low range under 4G >> + This one lets the user specify own low range under 4G > ~ This one let users specify own low range ... > > Other than this nitpick, LGTM This is Catalin's response a few days ago: Slightly more correct is "This one lets the user specify..." I didn't googled "This one lets", but I googled "It lets". I think he wrote it right. Both "the user" and "users" seem to be right. > > Acked-by: Baoquan He > >> for second kernel instead. >> 0: to disable low allocation. >> It will be ignored when crashkernel=X,high is not used >> @@ -832,7 +832,8 @@ >> [KNL, ARM64] range in low memory. >> This one lets the user specify a low range in the >> DMA zone for the crash dump kernel. >> - It will be ignored when crashkernel=X,high is not used. >> + It will be ignored when crashkernel=X,high is not used >> + or memory reserved is located in the DMA zones. >> >> cryptomgr.notests >> [KNL] Disable crypto self-tests >> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c >> index 18ba66c90991ea0..ac510fb6a2c0189 100644 >> --- a/arch/arm64/mm/init.c >> +++ b/arch/arm64/mm/init.c >> @@ -170,7 +170,8 @@ static void __init reserve_crashkernel(void) >> return; >> } >> >> - if (crash_low_size && reserve_crashkernel_low(crash_low_size)) { >> + if ((crash_base >= CRASH_ADDR_LOW_MAX) && >> + crash_low_size && reserve_crashkernel_low(crash_low_size)) { >> memblock_phys_free(crash_base, crash_size); >> return; >> } >> -- >> 2.25.1 >> > > . > -- Regards, Zhen Lei