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=-10.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 3CB53C433DB for ; Thu, 25 Feb 2021 15:46:41 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 E7BC564F18 for ; Thu, 25 Feb 2021 15:46:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E7BC564F18 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.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:References:Message-ID: Subject: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=S4ftTpsPYFXb2ojpKPLHrAy/OmtEbL/vokdh4Hh8diw=; b=0oBU51jn8ifcSPPwrR1V1fzkj ffmTKo069argMrm2PNp2plDXmpOtDNg5csKwsUAK/i8YEic173Bv0t25krOhNqeC9/NyNIVwzdYCP HRJUf00PdVfi91kShpnVhMFL4WedgX0OtRPODl5avXj8Mgf0gS4nXHIGVr/7D9kAsVEm9MWmkSTmM cqpHgohSBza1J9Xe5y9/TQrVi4u/KEn7O+YvO3KZ8/CpjmNOi5z5RxVzmVzCFjrIQzJxF2NGekBUW hwp3pDjKOSJfXPpxzdueFM7ZCBjA6nP8Cp42DrHY45frRa1mPq6M9I79kdHhjZ4yf5u7IpmFZugtK xvg8Yj+rQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lFIp9-000154-5v; Thu, 25 Feb 2021 15:45:07 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lFIp4-00013r-38 for linux-arm-kernel@lists.infradead.org; Thu, 25 Feb 2021 15:45:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614267899; 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=R6q+Q5NQOXbRifBC8SSR9ugXbvqn66/46WmsQY9vYlk=; b=ZRXhJZbSoMqpwQChL3OcXVo2r+89rlRb0Hr1xu/4X80G5sAWpUKTsizIs6PWeQgscxFVTf RIVZgn1rWBUgFgimPbwK3wXaQzFbkmAfxmZvYtuon7NxzKAG9wJUmQt1RhTT2saBaNyQ+Q nXmXExFjy1jD4BjOz0BqFwU6vzN3zEI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-355-1nkb0a5vOVKmgZhXqpt6CA-1; Thu, 25 Feb 2021 10:44:56 -0500 X-MC-Unique: 1nkb0a5vOVKmgZhXqpt6CA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E857C19611A8; Thu, 25 Feb 2021 15:44:53 +0000 (UTC) Received: from localhost (ovpn-12-80.pek2.redhat.com [10.72.12.80]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 547E45D767; Thu, 25 Feb 2021 15:44:49 +0000 (UTC) Date: Thu, 25 Feb 2021 23:44:46 +0800 From: Baoquan He To: Catalin Marinas Subject: Re: [PATCH v14 02/11] x86: kdump: make the lower bound of crash kernel reservation consistent Message-ID: <20210225154446.GI3553@MiWiFi-R3L-srv> References: <20210130071025.65258-1-chenzhou10@huawei.com> <20210130071025.65258-3-chenzhou10@huawei.com> <20210224143547.GB28965@arm.com> <20210225070717.GG3553@MiWiFi-R3L-srv> <20210225144237.GA23418@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210225144237.GA23418@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210225_104502_214531_80C4D8A1 X-CRM114-Status: GOOD ( 28.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: wangkefeng.wang@huawei.com, linux-doc@vger.kernel.org, Chen Zhou , huawei.libin@huawei.com, guohanjun@huawei.com, will@kernel.org, corbet@lwn.net, mingo@redhat.com, dyoung@redhat.com, John.P.donnelly@oracle.com, arnd@arndb.de, xiexiuqi@huawei.com, horms@verge.net.au, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, james.morse@arm.com, rppt@kernel.org, prabhakar.pkin@gmail.com, nsaenzjulienne@suse.de 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 02/25/21 at 02:42pm, Catalin Marinas wrote: > On Thu, Feb 25, 2021 at 03:08:46PM +0800, Baoquan He wrote: > > On 02/24/21 at 02:35pm, Catalin Marinas wrote: > > > On Sat, Jan 30, 2021 at 03:10:16PM +0800, Chen Zhou wrote: > > > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > > > > index da769845597d..27470479e4a3 100644 > > > > --- a/arch/x86/kernel/setup.c > > > > +++ b/arch/x86/kernel/setup.c > > > > @@ -439,7 +439,8 @@ static int __init reserve_crashkernel_low(void) > > > > return 0; > > > > } > > > > > > > > - low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0, CRASH_ADDR_LOW_MAX); > > > > + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, CRASH_ALIGN, > > > > + CRASH_ADDR_LOW_MAX); > > > > if (!low_base) { > > > > pr_err("Cannot reserve %ldMB crashkernel low memory, please try smaller size.\n", > > > > (unsigned long)(low_size >> 20)); > > > > > > Is there any reason why the lower bound can't be 0 in all low cases > > > here? (Sorry if it's been already discussed, I lost track) > > > > Seems like a good question. > > > > This reserve_crashkernel_low(), paired with reserve_crashkernel_high(), is > > used to reserve memory under 4G so that kdump kernel owns memory for dma > > buffer allocation. In that case, kernel usually is loaded in high > > memory. In x86_64, kernel loading need be aligned to 16M because of > > CONFIG_PHYSICAL_START, please see commit 32105f7fd8faa7b ("x86: find > > offset for crashkernel reservation automatically"). But for crashkernel > > low memory, there seems to be no reason to ask for 16M alignment, if > > it's taken as dma buffer memory. > > > > So we can make a different alignment for low memory only, e.g 2M. But > > 16M alignment consistent with crashkernel,high is also fine to me. The > > only affect is smaller alignment can increase the possibility of > > crashkernel low reservation. > > I don't mind the 16M alignment in both low and high base. But is there > any reason that the lower bound (third argument) cannot be 0 in both > reserve_crashkernel() (the low attempt) and reserve_crashkernel_low() > cases? The comment in reserve_crashkernel() only talks about the 4G > upper bound but not why we need a 16M lower bound. Ah, sorry, I must have mixed this one with the alignment of fixed memory region reservation in patch 1 when considering comments. Hmm, in x86 we always have memory reserved in low 1M, lower bound being 0 or 16M (kernel alignment) doesn't make difference on crashkernel low reservation. But for crashkernel reservation, the reason should be kernel loading alignment being 16M, please see commit 32105f7fd8faa7b ("x86: find offset for crashkernel reservation automatically"). So, for crashkernel low, keeping lower bound as 0 looks good to me, the only reason is just as patch log tells. And it can skip the unnecessary memblock searching under 16M since it will always fail, even though it won't matter much. Or changing it to CRASH_ALIGN as this patch is doing, and adding code comment, is also fine to me. Thanks Baoquan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel