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 B4DF1C64EC4 for ; Fri, 3 Mar 2023 11:30:31 +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:Date: Message-ID:From:References:CC:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=VGuEqdXrDm5u29tya6XUE9ntOg9KMI1X/PQ7ZkwKy30=; b=V0iN+NZ4iz24AlWBuwzUdlImwo BkAGJX98jFniV60oZER3cNALI7FGm4wMhsBInXyZvlu+I98EYLsrZYVpGCrE/zW0m52uL+us4AATa Nbqri9X2IpWELyI9uTxGL2zNDARsg3tIVlhMg+O/Z6l1BPYlt/VSAU0bR940ED87q3sqqJmMGA4Gr 3Tm7VeDGeRvfJ973WJWFIMdZ7+YrGZUKKIJlLO81aufA8y0jEAXOIrKvD9/61WYmZNKWYoyNieJzq jGOjezpOnSI0GmDVANBX+UpuHbUI1lfgeBrup9Uqx82Rz7LEgHcoxc7LMg79yr465j4/vny5Qs3nx ji9FuwsQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pY3bT-0069F3-6K; Fri, 03 Mar 2023 11:29:35 +0000 Received: from szxga03-in.huawei.com ([45.249.212.189]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pY3bM-006977-Rc; Fri, 03 Mar 2023 11:29:31 +0000 Received: from dggpemm500006.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4PSm2j1cP8znVcr; Fri, 3 Mar 2023 19:29:17 +0800 (CST) Received: from [10.174.178.55] (10.174.178.55) by dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Fri, 3 Mar 2023 19:29:18 +0800 Subject: Re: [PATCH v3] arm64: kdump: simplify the reservation behaviour of crashkernel=,high To: Baoquan He CC: , , , , , , References: <20230223124532.128744-1-bhe@redhat.com> <7971ddbe-aefb-271e-647c-59d81c5840a7@huawei.com> From: "Leizhen (ThunderTown)" Message-ID: Date: Fri, 3 Mar 2023 19:29:01 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [10.174.178.55] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500006.china.huawei.com (7.185.36.236) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230303_032929_269272_7C7E78B2 X-CRM114-Status: GOOD ( 16.01 ) 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 2023/3/3 11:01, Baoquan He wrote: > On 03/02/23 at 11:32am, Leizhen (ThunderTown) wrote: > ...... >>> @@ -166,31 +169,51 @@ static void __init reserve_crashkernel(void) >>> /* User specifies base address explicitly. */ >>> if (crash_base) { >>> fixed_base = true; >>> + search_base = crash_base; >>> crash_max = crash_base + crash_size; >>> } >>> >>> retry: >>> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN, >>> - crash_base, crash_max); >>> + search_base, crash_max); >>> if (!crash_base) { >>> /* >>> - * If the first attempt was for low memory, fall back to >>> - * high memory, the minimum required low memory will be >>> - * reserved later. >>> + * For crashkernel=size[KMG]@offset[KMG], print out failure >>> + * message if can't reserve the specified region. >>> */ >>> - if (!fixed_base && (crash_max == CRASH_ADDR_LOW_MAX)) { >>> + if (fixed_base) { >>> + pr_info("crashkernel reservation failed - memory is in use.\n"); >> >> How about changing pr_info to pr_warn? >> >>> + return; >>> + } >>> + >>> + /* >>> + * For crashkernel=size[KMG], if the first attempt was for >>> + * low memory, fall back to high memory, the minimum required >>> + * low memory will be reserved later. >>> + */ >>> + if (!high && crash_max == CRASH_ADDR_LOW_MAX) { >>> crash_max = CRASH_ADDR_HIGH_MAX; >>> + search_base = CRASH_ADDR_LOW_MAX; >>> crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE; >>> goto retry; >>> } >>> >>> + /* >>> + * For crashkernel=size[KMG],high, if the first attempt was >>> + * for high memory, fall back to low memory. >>> + */ >>> + if (high && crash_max == CRASH_ADDR_HIGH_MAX) { >> >> Adding unlikely to indicate that it is rare would be better. >> >> if (unlikely(high && crash_max == CRASH_ADDR_HIGH_MAX)) > > Rethink about this and checked code in kernel, seems likely|unlikely are > mostly used in highly frequent execution branch optimize code path, while > crashkernel resevatoin is one time execution during boot, we may not > need to bother to add unlikely. What do you think? OK. > > >> >>> + crash_max = CRASH_ADDR_LOW_MAX; >>> + search_base = 0; >>> + goto retry; >>> + } >>> pr_warn("cannot allocate crashkernel (size:0x%llx)\n", >>> crash_size); >>> return; >>> } >>> >>> - if ((crash_base > CRASH_ADDR_LOW_MAX - crash_low_size) && >>> - crash_low_size && reserve_crashkernel_low(crash_low_size)) { >>> + if ((crash_base >= CRASH_ADDR_LOW_MAX) && crash_low_size && >>> + reserve_crashkernel_low(crash_low_size)) { >>> memblock_phys_free(crash_base, crash_size); >>> return; >>> } >>> >> >> -- >> Regards, >> Zhen Lei >> > > . > -- Regards, Zhen Lei _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel