Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp742784imw; Mon, 4 Jul 2022 19:23:31 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uMQ6B932nXLM/evwekStT+0hhi5EaF72cElkUeVi36LvWvTGIPrQlD5hZ021uM8Z5k2Wap X-Received: by 2002:a17:906:64d0:b0:722:e8c6:9169 with SMTP id p16-20020a17090664d000b00722e8c69169mr31932205ejn.206.1656987811374; Mon, 04 Jul 2022 19:23:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656987811; cv=none; d=google.com; s=arc-20160816; b=j2sLcV7dHWwZBIL+WEQDF0U/YoGngfwSZV/LdfRyZMsWuljg9TQFSOF7yKvqqLbzk4 PVIwlmXkA/eKNtHgdXmndFwhY/34Mp0r6MaOWtnKBn3Wlt5cb3MIrfc4NWtLznXIkKxz K1O9bJgX57B6AGI6cbIsQ/byREPj44Pc4/jnkAs6pqlcesvJuAetKzzhzg5xZMD/FSLu 70mrRxiP6o4T4bz7BTpzNkPWGAOcP97caMAmxz68GT7EBldlbSOwRDqfYfaq+L1BuHmz WIUUo8Nh9uJP6gLlKOuwyXtCK8T+57lNc1kqwxpIt+xXtaYd/AnWuvx1x/AmdZomd84K FeQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=0NC/eC1lPxFvKCJBfy26CWHeOBX1P9jbiKqcYaXCqrA=; b=Nd05TqPljxXcecUsj/5V2Svg2sv6TkG2SpVDyQQ6QoxpSWb19WBKlCd8AOJ7vtP60K XHjNMGHLdbeVahQ/f3yWh2DnKuTe9c9PYBFYVWVNcQHfAYaSKSWRF+X4kVBa3sQlgDO4 BQoMecE6FTgtIiK1zReV3RKtpwHQWTJ2DVgrL6fwT2V9MVcozt+QYYUzhghIiMJcoXZQ zbxLczcwbHguQuNcIZ0yfoNOTL8blM+0ZVkY1TY3sX8Z101pjNSIP8OFrifiuoemP/YI 5CmolnKI2zBjRCHEx18joPXJtEiPD74CD7ekIQ+2fvLdTa1EiHqAa7ub8qHrgcpnf2Bh 4TyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DU32cKgJ; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n4-20020a509344000000b0042ddac25209si21776449eda.92.2022.07.04.19.23.06; Mon, 04 Jul 2022 19:23:31 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DU32cKgJ; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233573AbiGEB5H (ORCPT + 99 others); Mon, 4 Jul 2022 21:57:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36598 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229453AbiGEB5F (ORCPT ); Mon, 4 Jul 2022 21:57:05 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9FE82101F5 for ; Mon, 4 Jul 2022 18:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656986223; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0NC/eC1lPxFvKCJBfy26CWHeOBX1P9jbiKqcYaXCqrA=; b=DU32cKgJAREXB4FTg6diRVnjKNTpMlP3l7wTvxrxjkuC+jITN/uRlIgtnyg68hjCD+vmVh pOPcph0Jjb79cAzwSc/umgvdYZsmmGFND9OskojCR4uc8jmUGNwKKBu4nd6dhPMD3DjO0k uiR2qxDu9r0dgduHD52b70MT8HeKf/o= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-100-uRHuuSnmMVexQhT7n8YAwA-1; Mon, 04 Jul 2022 21:57:00 -0400 X-MC-Unique: uRHuuSnmMVexQhT7n8YAwA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 32BFA1C05148; Tue, 5 Jul 2022 01:57:00 +0000 (UTC) Received: from localhost (ovpn-13-74.pek2.redhat.com [10.72.13.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 788822166B26; Tue, 5 Jul 2022 01:56:59 +0000 (UTC) Date: Tue, 5 Jul 2022 09:56:55 +0800 From: Baoquan He To: Kaihao Bai Cc: ebiederm@xmission.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, baolin.wang@linux.alibaba.com Subject: Re: [PATCH 0/2] kexec: accumulate and release the size of crashkernel Message-ID: References: <1656934895-12334-1-git-send-email-carlo.bai@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1656934895-12334-1-git-send-email-carlo.bai@linux.alibaba.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,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 07/04/22 at 07:41pm, Kaihao Bai wrote: > Currently x86 and arm64 support to reserve low memory range for > crashkernel. When crashkernel=Y,low is defined, the main kernel would > reserve another memblock (instead of crashkernel=X,high, which stored > in crashk_res) for crashkernel and store it in crashk_low_res. > > The implementations of get_crash_size and crash_shrink_size do not > consider the extra reserved memory range if it exists. Thus, firstly > accumulate this range on the size of crashkernel and export the size > by /sys/kernel/kexec_crash_size. > > If getting the input of /sys/kernel/kexec_crash_size, both reserved ranges > might be released if the new size is smaller than current size. The order > of release is (crashk_res -> crashk_low_res). Only if the new size defined > by the user is smaller than the size of low memory range, continue to > release the reserved low memory range after completely releasing the high > memory range. Sorry, I don't like this patchset. I bet you don't encounter a real problem in your product environment. Regarding crashkernel=,high|low, the ,low memory is for DMA and requirement from memory under lower range. The ,high meomry is for kernel/initrd loading, kernel data, user space program running. When you configure crashkernel= in your system, you need evaluate what value is suitable. /sys/kernel/kexec_crash_size is an interface you can make use of to tune the memory usage. People are not suggested to free all crashkernel reservation via the interface. So, please leave this as is, unless you have a real case where this change is needed. Thanks Baoquan