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 49BFCC05027 for ; Thu, 2 Feb 2023 02:56:55 +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=wXHEqMRtOch/DKo7vk1PNy5HqLbdwbTw5oj2urSaiE8=; b=YLcbMLqI0MiNvP VidCpT8COQKeEg82SoZfwY44hmQ6nZ/QNgAlap1r1Mbn7TfIrtm5U22/6O3lvDc8s/UFmbEzkQlY5 vMWvbgLNeB2yRlGLo6WSOcKJ4amZqgKUqd9OEn6NLdm0Ef6DX0RyLIvtdxJ78bV8EbHCviJg9It+A DmyVFYvjrpnZ+yZWLRu6dYp0kzemw6+EvG+7p9SwQIFXMBYsxbRMQbOIFMTCRRGn9X0VjcA3T1gUO jJxhuhmS8VuyEEk5fMmn5znQdgXTvRBm4KUCkkcUWtJVXxWOPEYOGGy7XMyIFc6O4VKygf3AKQcSD f5g2lQnk9kl2k/Me5O9A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNPlO-00EBki-6L; Thu, 02 Feb 2023 02:55:50 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNPlF-00EBir-PB for linux-arm-kernel@lists.infradead.org; Thu, 02 Feb 2023 02:55:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675306539; 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=XLBXtd6NgriQ7A5ZWXztbyUCM7WFy5RfjYy2td4k7fE=; b=gENN3IK9RW/Jy52NGL29T2RTuld/0LMbwlSxtl+BJlaAvuj5Egl4TY4ZKOm6BVEAB1/3ST oj2W9AxAfxD7Up+sX4Use7hLF4Nou0Kt5x66/cVnls/r0uuZK95LMcjz1F71azw2bezJuo /IvSbDV2d+7ZBIeP35abi1EgDdzrXzg= 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-426-efmawRduNwu8WBWqSoSN_g-1; Wed, 01 Feb 2023 21:55:36 -0500 X-MC-Unique: efmawRduNwu8WBWqSoSN_g-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EFBA6101A521; Thu, 2 Feb 2023 02:55:35 +0000 (UTC) Received: from localhost (ovpn-12-116.pek2.redhat.com [10.72.12.116]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 983BE43FBA; Thu, 2 Feb 2023 02:55:34 +0000 (UTC) Date: Thu, 2 Feb 2023 10:55:30 +0800 From: Baoquan He To: Catalin Marinas Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, will@kernel.org, thunder.leizhen@huawei.com, John.p.donnelly@oracle.com, wangkefeng.wang@huawei.com Subject: Re: [PATCH 1/2] arm64: kdump: simplify the reservation behaviour of crashkernel=,high Message-ID: References: <20230117034921.185150-1-bhe@redhat.com> <20230117034921.185150-2-bhe@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230201_185541_912604_04A411ED X-CRM114-Status: GOOD ( 34.77 ) 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 02/01/23 at 05:07pm, Catalin Marinas wrote: > On Wed, Feb 01, 2023 at 01:57:17PM +0800, Baoquan He wrote: > > On 01/24/23 at 05:36pm, Catalin Marinas wrote: > > > On Tue, Jan 17, 2023 at 11:49:20AM +0800, Baoquan He wrote: > > > > On arm64, reservation for 'crashkernel=xM,high' is taken by searching for > > > > suitable memory region up down. If the 'xM' of crashkernel high memory > > > > is reserved from high memory successfully, it will try to reserve > > > > crashkernel low memory later accoringly. Otherwise, it will try to search > > > > low memory area for the 'xM' suitable region. > > > > > > > > While we observed an unexpected case where a reserved region crosses the > > > > high and low meomry boundary. E.g on a system with 4G as low memory end, > > > > user added the kernel parameters like: 'crashkernel=512M,high', it could > > > > finally have [4G-126M, 4G+386M], [1G, 1G+128M] regions in running kernel. > > > > This looks very strange because we have two low memory regions > > > > [4G-126M, 4G] and [1G, 1G+128M]. Much explanation need be given to tell > > > > why that happened. > > > > > > > > Here, for crashkernel=xM,high, search the high memory for the suitable > > > > region above the high and low memory boundary. If failed, try reserving > > > > the suitable region below the boundary. Like this, the crashkernel high > > > > region will only exist in high memory, and crashkernel low region only > > > > exists in low memory. The reservation behaviour for crashkernel=,high is > > > > clearer and simpler. > > > > > > Well, I guess it depends on how you look at the 'high' option: is it > > > permitting to go into high addresses or forcing high addresses only? > > > IIUC the x86 implementation has a similar behaviour to the arm64 one, it > > > allows allocation across boundary. > > > > Hmm, x86 has no chance to allocate a memory region across 4G boundary > > because it reserves many small regions to map firmware, pci bus, etc > > near 4G. E.g one x86 system has /proc/iomem as below. I haven't seen a > > x86 system which doesn't look like this. > > > > [root@ ~]# cat /proc/iomem > [...] > > fffc0000-ffffffff : Reserved > > 100000000-13fffffff : System RAM > > Ah, that's why we don't see this problem on x86. > > Alright, for consistency I'm fine with having the same logic on arm64. I > guess we don't need the additional check on whether the 'high' > allocation reserved at least 128MB in the 'low' range. If it succeeded > and the start is below 4GB, it's guaranteed that it got the full > allocation in the 'low' range. I haven't checked whether your patch > cleaned this up already, if not please do in the next version. Yes, that checking has been cleaned away in this patch. > > And as already asked, please fold the comments with the same patch, it's > easier to read. Sure, will do. Thanks a lot for reviewing. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel