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 186B3C433F5 for ; Fri, 6 May 2022 13:17:49 +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=cAAX1ej8iZtuI+ciyw/eGr9wrmzNnYEl7oJyLkUhss4=; b=ACRHhkqUup4Qn4 i9B+A/VxACP5M20D/9N1yJ4c1GWgeEhn6F/WFS+OmTpbekHcK8lxDVWP9G1PQWcMBNlrz9I911fpF XXXbYSazt2xb714GwlcsHUDO24Iia3PrZjSRBCLQksTiQIul1bCQuUz9JHvU1XTGr1ly8qceuC2jP QIJeUjLmgaoEmlUBQZ5HtkuicsGnVUirRO8WqyiGZOfXA1lw6X1MLJp74vJV14bqODvEOLGwAgDbg KKyBc6xNYowequnY+1yxQVi5sWKZ3Uym7zrqM+KVNa+0TAdaM8KqSfYpkh+h71H6lfn9wV1nArZaP DIOwLJRuh/VGqR180oTA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmxoz-003NMf-VU; Fri, 06 May 2022 13:16:38 +0000 Received: from us-smtp-delivery-74.mimecast.com ([170.10.129.74]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmxoi-003NCK-La for linux-arm-kernel@lists.infradead.org; Fri, 06 May 2022 13:16:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651842979; 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=8wPDA2gsA8PtLts/9kHE8ZGbzgkULXlMPGcav5wmzQU=; b=Amim3RWL9YsbYAbrtlCQnM3o6aegJZDvvec5yF4icwg7ZKKv572HCqzefypN8K5dYCUI+D GPptyti8FRt01lUf7XJ/xlBESixqgJJznbcm1SRQ3KbOMi6a7lH3H7eNsWmeIRT2zSRpfC tm8egPf+jst3jBco9erDHRNNIR7T+bI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-583-j9olosgBNA2Z3YsZN10Vzw-1; Fri, 06 May 2022 09:16:14 -0400 X-MC-Unique: j9olosgBNA2Z3YsZN10Vzw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7D9F8803E2E; Fri, 6 May 2022 13:16:13 +0000 (UTC) Received: from localhost (ovpn-13-105.pek2.redhat.com [10.72.13.105]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A3EAD463EDC; Fri, 6 May 2022 13:16:11 +0000 (UTC) Date: Fri, 6 May 2022 21:16:08 +0800 From: Baoquan He To: "Leizhen (ThunderTown)" Cc: Catalin Marinas , Thomas Gleixner , Ingo Molnar , Borislav Petkov , 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 , John Donnelly , Dave Kleikamp Subject: Re: [PATCH v23 3/6] arm64: kdump: Reimplement crashkernel=X Message-ID: References: <20220505091845.167-1-thunder.leizhen@huawei.com> <20220505091845.167-4-thunder.leizhen@huawei.com> <189f24a8-9e9b-b3e9-7ac5-935433ea575b@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <189f24a8-9e9b-b3e9-7ac5-935433ea575b@huawei.com> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220506_061620_818417_7A2DBD93 X-CRM114-Status: GOOD ( 29.46 ) 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 05/06/22 at 11:22am, Leizhen (ThunderTown) wrote: ...... > >> @@ -118,8 +159,7 @@ static void __init reserve_crashkernel(void) > >> if (crash_base) > >> crash_max = crash_base + crash_size; > >> > >> - /* Current arm64 boot protocol requires 2MB alignment */ > >> - crash_base = memblock_phys_alloc_range(crash_size, SZ_2M, > >> + crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN, > >> crash_base, crash_max); > >> if (!crash_base) { > >> pr_warn("cannot allocate crashkernel (size:0x%llx)\n", > > > > I personally like this but let's see how the other thread goes. I guess > > Me too. This fallback complicates code logic more than just a little. > I'm not sure why someone would rather add fallback than change the bootup > options to crashkernel=X,[high|low]. Perhaps fallback to high/low is a better > compatible and extended mode when crashkernel=X fails to reserve memory. And > the code logic will be much clearer. The fallback does complicates code, while it was not made at the beginning, but added later. The original crahskernel=xM can only reserve low memory under 896M on x86 to be back compatible with the case in which normal kernel is x86_64, while kdump kernel could be i386. Then customer complained why crashkernel=xM can't be put anywhere so that they don't need to know the details of limited low memory and huge high memory fact in system. The implementation of fallback is truly complicated, but its use is quite simple. And it makes crashkernel reservation setting simple. Most of users don't need to know crashkernel=,high, ,low things, unless the crashkernel region is too big. Nobody wants to take away 1G or more from low memory for kdump just in case bad thing happens, while normal kernel itself is seriously impacted by limited low memory. > > //parse crashkernel=X //To simplify the discussion, Ignore [@offset] > crash_base = memblock_phys_alloc_range() > if (!crash_base || /* crashkernel=X is not specified */) { > //parse crashkernel=X,[high,low] > //reserve high/low memory > } > > So that, the following three modes are supported: > 1) crashkernel=X[@offset] > 2) crashkernel=X,high crashkernel=X,low > 3) crashkernel=X[@offset] crashkernel=X,high [crashkernel=Y,low] > > For case 3), try "crashkernel=X[@offset]" first, if it can not work, fallback > to "crashkernel=X,high crashkernel=X,low". This looks better than the old "crashkernel=X" > fallback ---- Select a region under 4G first, and fall back to reserve region above 4G. Don't get it. Aren't they the same? > > Note: when the X of crashkernel=X and crashkernel=X,high are the same, It's equivalent > to the old "crashkernel=X" fallback. > > > if we want a fallback, it would come just before the check the above: > > > > if (!crash_base && crash_max != CRASH_ADDR_HIGH_MAX) { > > /* attempt high allocation with default low */ > > if (!crash_low_size) > > crash_low_size = some default; > > crash_max = CRASH_ADDR_LOW_MAX; > > crash_max = CRASH_ADDR_HIGH_MAX; We should fallback to high memory now. > > > crash_base = memblock_phys_alloc_range(); > > } > > > > Well, I guess we end up with your earlier proposal but I think I > > understand it better now ;). > > > > -- > Regards, > Zhen Lei > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel