Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp618754pxk; Wed, 2 Sep 2020 10:12:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwoMZ8nmPSXlcRPCmlS3yI8yr6GrW0mvgCB/TWvwHD/coJVch3xPKNmZ2P8oZIZb8gstB9E X-Received: by 2002:aa7:cb8f:: with SMTP id r15mr1097866edt.356.1599066759790; Wed, 02 Sep 2020 10:12:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599066759; cv=none; d=google.com; s=arc-20160816; b=tSdUJT6/qT9fMXtrMIoetlutLF49ICwfS6FIiBV7qmsI4FunPBAABatBM4FvRroVNb PdvnyyAh+VUZFBjtWGCZbMCqDbZDOlBvE/ZI/AjkSqZgq2/nMcPrgAgZ7STGXDu+eITV 8rQRoT2KhhcAmjZCVpDutgoVPMYpMFgh/+hp5IJLKCsEpbxJBK6fPRK+mF3DLm1WPpnq xJv+kEDN5QJXiBxlTZJD8BybCQixQFxJ4ofUUJoJTfZPAUz80+5c88DTKSzQi4niueqG bO+p2pNmP3H1uyz6vTZNTRdTZWf4FJZ6Kduwp6ZW1ZZ/gkn5sXmK4m3fBF6336/7OIVA AHRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=V9C4/x9c09MjBZ9+QdfxkKLEXzuK6vCkeBFlkQt4rO0=; b=d3U+lnnP6aVyPtOtWPL2GyZIRoaksM5ozGE0ClQvUcOD8T6JdxLmHciGpzpVWxFidU WFe9Bj6z3MK8asZ9BlBeENzniDOgOZtG+MZ94B+Gjrs+t4B/Xbl3Wfs3j1YVCmF6INo7 fJaa7hJkvk1t/n02vO0Zcb2Ob5jm+x/WGBxpkWrxo5+baQ5ENfa4zriTelWFCHeKA73Z 9k14uW3SN5So8/3Di7XTJwCyRkJRMfXF3ukZBly4kF4V1eqohTcVbIHBbPHxmAB9XCXr 0WdV269U02spNCVKAo5ZijQ/IqIUcXYKqyZ+GpbzCVv3ZcNyxJCMDwOx6EHNrIdL9ojt CXUA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a7si73394ejd.422.2020.09.02.10.12.15; Wed, 02 Sep 2020 10:12:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728273AbgIBRJU (ORCPT + 99 others); Wed, 2 Sep 2020 13:09:20 -0400 Received: from mail.kernel.org ([198.145.29.99]:35004 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727088AbgIBRJT (ORCPT ); Wed, 2 Sep 2020 13:09:19 -0400 Received: from gaia (unknown [46.69.195.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 81C1520709; Wed, 2 Sep 2020 17:09:14 +0000 (UTC) Date: Wed, 2 Sep 2020 18:09:11 +0100 From: Catalin Marinas To: Chen Zhou Cc: will@kernel.org, james.morse@arm.com, tglx@linutronix.de, mingo@redhat.com, dyoung@redhat.com, bhe@redhat.com, corbet@lwn.net, John.P.donnelly@oracle.com, prabhakar.pkin@gmail.com, bhsharma@redhat.com, horms@verge.net.au, robh+dt@kernel.org, arnd@arndb.de, nsaenzjulienne@suse.de, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-doc@vger.kernel.org, guohanjun@huawei.com, xiexiuqi@huawei.com, huawei.libin@huawei.com, wangkefeng.wang@huawei.com Subject: Re: [PATCH v11 3/5] arm64: kdump: reimplement crashkernel=X Message-ID: <20200902170910.GB16673@gaia> References: <20200801130856.86625-1-chenzhou10@huawei.com> <20200801130856.86625-4-chenzhou10@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200801130856.86625-4-chenzhou10@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 01, 2020 at 09:08:54PM +0800, Chen Zhou wrote: > There are following issues in arm64 kdump: > 1. We use crashkernel=X to reserve crashkernel below 4G, which > will fail when there is no enough low memory. > 2. If reserving crashkernel above 4G, in this case, crash dump > kernel will boot failure because there is no low memory available > for allocation. > 3. Since commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32"), > if the memory reserved for crash dump kernel falled in ZONE_DMA32, > the devices in crash dump kernel need to use ZONE_DMA will alloc > fail. > > To solve these issues, change the behavior of crashkernel=X. > crashkernel=X tries low allocation in ZONE_DMA, and fall back to > high allocation if it fails. > > If requized size X is too large and leads to very little free memory > in ZONE_DMA after low allocation, the system may not work normally. > So add a threshold and go for high allocation directly if the required > size is too large. The value of threshold is set as the half of > the low memory. > > If crash_base is outside ZONE_DMA, try to allocate at least 256M in > ZONE_DMA automatically. "crashkernel=Y,low" can be used to allocate > specified size low memory. Except for the threshold to keep zone ZONE_DMA memory, reserve_crashkernel() looks very close to the x86 version. Shall we try to make this generic as well? In the first instance, you could avoid the threshold check if it takes an explicit ",high" option. -- Catalin