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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 86581C433EF for ; Wed, 15 Dec 2021 11:05:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=CVSAAVRiUL9N+gHclhQ+xd1kcbl8S8JeFvFzXdy0qkE=; b=0/Sv23psmqK3Lq p0HB4PHT/tX2cwCi+ZWHnUway19eRTofdPaaFSic8WP/fubhFWTevph51e5iSHpFGf8wgIQp3PKUP qn3VGQM4wTZVyDk3nIo3iG72EK7J9Gz8JaW85Ge9GwA/UpXYhftyrGiSKFijbKK2+BlQZH/o0sbnY Gb6wSao3mFrRnrdukVl4uFFAY5vQC9n+uuiU19ul0ueNML26GNrOYEm6TulLSdTwYXtzlefemJJbJ dW7Y99Kv/CII995dtLZzJNG2XwpAY9yida2d+EJ3VcjUO+bcYj/4wNYAnfX3gSQef8ep/xhbaVeHB xVKrxc/bNvFxOHFb6JCw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mxS50-000Nbd-7q; Wed, 15 Dec 2021 11:04:14 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mxS25-000M4G-7o; Wed, 15 Dec 2021 11:01:14 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id EA520B81EB2; Wed, 15 Dec 2021 11:01:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E79F5C34605; Wed, 15 Dec 2021 11:01:06 +0000 (UTC) Date: Wed, 15 Dec 2021 11:01:03 +0000 From: Catalin Marinas To: Baoquan He Cc: Borislav Petkov , Zhen Lei , Thomas Gleixner , Ingo Molnar , x86@kernel.org, "H . Peter Anvin" , linux-kernel@vger.kernel.org, Dave Young , Vivek Goyal , Eric Biederman , kexec@lists.infradead.org, Will Deacon , linux-arm-kernel@lists.infradead.org, Rob Herring , Frank Rowand , devicetree@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Randy Dunlap , Feng Zhou , Kefeng Wang , Chen Zhou Subject: Re: [PATCH v17 02/10] x86: kdump: make the lower bound of crash kernel reservation consistent Message-ID: References: <20211210065533.2023-1-thunder.leizhen@huawei.com> <20211210065533.2023-3-thunder.leizhen@huawei.com> <20211215034219.GB10336@MiWiFi-R3L-srv> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211215034219.GB10336@MiWiFi-R3L-srv> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211215_030113_440134_DD53DB69 X-CRM114-Status: GOOD ( 22.39 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Wed, Dec 15, 2021 at 11:42:19AM +0800, Baoquan He wrote: > On 12/14/21 at 07:24pm, Catalin Marinas wrote: > > On Tue, Dec 14, 2021 at 08:07:58PM +0100, Borislav Petkov wrote: > > > On Fri, Dec 10, 2021 at 02:55:25PM +0800, Zhen Lei wrote: > > > > From: Chen Zhou > > > > > > > > The lower bounds of crash kernel reservation and crash kernel low > > > > reservation are different, use the consistent value CRASH_ALIGN. > > > > > > A big WHY is missing here to explain why the lower bound of the > > > allocation range needs to be 16M and why was 0 wrong? > > > > I asked the same here: > > > > https://lore.kernel.org/r/20210224143547.GB28965@arm.com > > > > IIRC Baoquan said that there is a 1MB reserved for x86 anyway in the > > lower part, so that's equivalent in practice to starting from > > CRASH_ALIGN. > > Yeah, even for i386, there's area reserved by BIOS inside low 1M. > Considering the existing alignment CRASH_ALIGN which is 16M, we > definitely have no chance to get memory starting from 0. So starting > from 16M can skip the useless memblock searching, and make the > crashkernel low reservation consisten with crashkernel reservation on > allocation code. That's the x86 assumption. Is it valid for other architectures once the code has been made generic in patch 6? It should be ok for arm64, RAM tends to start from higher up but other architectures may start using this common code. If you want to keep the same semantics as before, just leave it as 0. It's not that the additional lower bound makes the search slower. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel