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=-12.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 0DC13C433DB for ; Thu, 25 Feb 2021 07:14:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BD88264E85 for ; Thu, 25 Feb 2021 07:14:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233153AbhBYHOT (ORCPT ); Thu, 25 Feb 2021 02:14:19 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:37894 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233860AbhBYHKc (ORCPT ); Thu, 25 Feb 2021 02:10:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614236940; 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=n2zycR982n4IDyIo8S5QQfcm9Yun3ac6bR32xROLXzE=; b=LVXITeohuo8skAC43UyCD+K5P+gKRXbPdDN9JeRak/c2vMXtlQdHOWxOIoqz18QqFSYGOq O5oMDwHcBW02ohCsbnxQhDd9l6kW2wFmHF/L/6FSPt5xOT/1+lb2ry6KPiXPfRzSEs3eW9 nJa0g/ArJql5QNYStsva9KMFZ00vgAA= 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-288-X_Aye50ENleUgxsX6198tw-1; Thu, 25 Feb 2021 02:08:56 -0500 X-MC-Unique: X_Aye50ENleUgxsX6198tw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8D7C7803F57; Thu, 25 Feb 2021 07:08:52 +0000 (UTC) Received: from localhost (ovpn-12-51.pek2.redhat.com [10.72.12.51]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C79BB19727; Thu, 25 Feb 2021 07:08:48 +0000 (UTC) Date: Thu, 25 Feb 2021 15:08:46 +0800 From: Baoquan He To: Catalin Marinas Cc: Chen Zhou , mingo@redhat.com, tglx@linutronix.de, rppt@kernel.org, dyoung@redhat.com, will@kernel.org, nsaenzjulienne@suse.de, corbet@lwn.net, John.P.donnelly@oracle.com, prabhakar.pkin@gmail.com, horms@verge.net.au, robh+dt@kernel.org, arnd@arndb.de, james.morse@arm.com, xiexiuqi@huawei.com, guohanjun@huawei.com, huawei.libin@huawei.com, wangkefeng.wang@huawei.com, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org Subject: Re: [PATCH v14 02/11] x86: kdump: make the lower bound of crash kernel reservation consistent Message-ID: <20210225070717.GG3553@MiWiFi-R3L-srv> References: <20210130071025.65258-1-chenzhou10@huawei.com> <20210130071025.65258-3-chenzhou10@huawei.com> <20210224143547.GB28965@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210224143547.GB28965@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Thanks Baoquan 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 B586DC433DB for ; Thu, 25 Feb 2021 07:10:23 +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 59E7A64ED3 for ; Thu, 25 Feb 2021 07:10:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 59E7A64ED3 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=P5CI41sWtGoMgyi+IObHb0g+GsHUSE+pJawgztGIyx4=; b=qNsB86HpIrXfPovY0D1lUGMhz aEiKiow/y9kvB656Udrnk4t2K/BMlbzDu6+iaRbbwUZr7+f5OKmv/AcA1o3nDAd8yfzbSqYl/F8Pj YwG2vtw75Fzezh9Ap33S1QaRzZGsHVAJTegScAVWSxOZ3Uw5taNdNfzMFzKegL3mOLHSod54af0mN qF9SP2b/omG2cINMz9KKPTnudC8809pi/8In2O6ZOhGW+RIX47r/nn5KTdu4R7BYSP+LyVkKKOx4i KdoOpGK8MMla3+Ws40olIblIS1Q5qPESAO+LoZJkUocvuPnJkMcaqcjfMFL3pZZJp5Z35P2Xggp+U R6/k4zUaQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lFAlo-0001hv-TD; Thu, 25 Feb 2021 07:09:08 +0000 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lFAll-0001fk-VL for linux-arm-kernel@lists.infradead.org; Thu, 25 Feb 2021 07:09:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614236941; 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=n2zycR982n4IDyIo8S5QQfcm9Yun3ac6bR32xROLXzE=; b=Lrhf/L1O/tOYO149lQeBOIQnO8V4DcIAxget3KpRDVgP4NsVddLVIoClBneQoLtuGqTZGx BFmoR26MO6ciCq3lMUSlq/rjaMyM2fTiBoO7ZXo/iC+LC9lgMEbfbrpJH0uR5BcugUhuFA uENbC9qNjQZD0PQZ41ZlOCy0QOqax2M= 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-288-X_Aye50ENleUgxsX6198tw-1; Thu, 25 Feb 2021 02:08:56 -0500 X-MC-Unique: X_Aye50ENleUgxsX6198tw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8D7C7803F57; Thu, 25 Feb 2021 07:08:52 +0000 (UTC) Received: from localhost (ovpn-12-51.pek2.redhat.com [10.72.12.51]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C79BB19727; Thu, 25 Feb 2021 07:08:48 +0000 (UTC) Date: Thu, 25 Feb 2021 15:08: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: <20210225070717.GG3553@MiWiFi-R3L-srv> References: <20210130071025.65258-1-chenzhou10@huawei.com> <20210130071025.65258-3-chenzhou10@huawei.com> <20210224143547.GB28965@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210224143547.GB28965@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210225_020906_061872_F210681B X-CRM114-Status: GOOD ( 17.77 ) 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/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. Thanks Baoquan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lFAlj-0001fl-3k for kexec@lists.infradead.org; Thu, 25 Feb 2021 07:09:04 +0000 Date: Thu, 25 Feb 2021 15:08:46 +0800 From: Baoquan He Subject: Re: [PATCH v14 02/11] x86: kdump: make the lower bound of crash kernel reservation consistent Message-ID: <20210225070717.GG3553@MiWiFi-R3L-srv> References: <20210130071025.65258-1-chenzhou10@huawei.com> <20210130071025.65258-3-chenzhou10@huawei.com> <20210224143547.GB28965@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210224143547.GB28965@arm.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Catalin Marinas 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 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. Thanks Baoquan _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec