Message ID | 20230324131838.409996-2-bhe@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp624616vqo; Fri, 24 Mar 2023 06:27:53 -0700 (PDT) X-Google-Smtp-Source: AKy350Z28g1r9i479gRJJfA/PL2yLBTJpxxxYv4ZP1xPKR74eGJ8sQ76kr0nEi81XAV/QNoO8RxW X-Received: by 2002:a17:906:478a:b0:930:fded:5bf2 with SMTP id cw10-20020a170906478a00b00930fded5bf2mr3325723ejc.52.1679664473679; Fri, 24 Mar 2023 06:27:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679664473; cv=none; d=google.com; s=arc-20160816; b=I0OnHpmVMnbPN6Vb7FM9E9O915c9Mtr+OoeWZMZ5Ny/GhKhlPtcwV5/lurtOx/+DTM G16hcepsZ+othP9IFKD0/jskO3N7IOLkre30o9G/A/soOIGcoyASTh5PdpKldjZSrqXb JJIbx7gHboib7m+sEh7F4KA192oqeCisAzI7MSI0CTPzmRxQtcnsM7W18xg21e38ujer 4csNAoFrVRfxfeJV6UdRUkAOXuKJ28/v27/1Cp20BiwU2Qpj6yjxMGtx9Wuhwm4KMHlj sHz020r6jiZP1+hZqnpjUSEzeLv97L3alIA48YiIFAGgjMuBM1a3vtMffx/EC6jonkOo wVXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=LJ2yqGl1dqMrrwi5w6gpxIhSEUS+wEm3daG74vQ+ZWo=; b=ex2MGSWNfzrHxaZaJsbN+vbf905NB39mvOq6QbVhL983lPGYkzpFChOCWy4sdDGk4Q o/Xm7biR48LVlYk+8tTSSX6jogKD4blrut1aR23eCDl5PyFxQpFO9x/p8CHvq0SnZWpd DQT6qG5APpT3rZjzO9L1rBDCmgZnsItapgCY4k/1kJ7+ZbsNaUL0MVr8VbcGJd1uxLIo YBY2oJsz1gDpul3/JDQeInz7sk+Q4kM1ZH6rcGA+Wg1WuSTuwg0kB9tJ2r22kV6OYjom 5YCkzVbuGzs8SjSFJHRxXTEtqFdeQxtuIDkPsjnVwKRH8J6VrEU4SiNDIEkAVX7BEVg1 uf2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SJOKT5Vg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g10-20020aa7c84a000000b005021d17243csi1971164edt.259.2023.03.24.06.27.30; Fri, 24 Mar 2023 06:27:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SJOKT5Vg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232032AbjCXNT4 (ORCPT <rfc822;ezelljr.billy@gmail.com> + 99 others); Fri, 24 Mar 2023 09:19:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232038AbjCXNTt (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 24 Mar 2023 09:19:49 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C4F0199B for <linux-kernel@vger.kernel.org>; Fri, 24 Mar 2023 06:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679663939; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LJ2yqGl1dqMrrwi5w6gpxIhSEUS+wEm3daG74vQ+ZWo=; b=SJOKT5Vg+HrdN1gpREgUU1fKn/qanwHZMR1gSlahryCQUAfQmSQnncA5zt103EUt4rMdqf 8SjkOMc8NSFQoSMXQ2LUGU39BcZKKi2guQOwi3rjCsPPiDO3C8D4mFCMFyqUx8UMvPefbc ss1r9NNEoG3DcKvxsv3fAxXNoMP5lmY= 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-639-YFzlrtPDMX2bsaJljY9CHg-1; Fri, 24 Mar 2023 09:18:54 -0400 X-MC-Unique: YFzlrtPDMX2bsaJljY9CHg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BAF4B801779; Fri, 24 Mar 2023 13:18:53 +0000 (UTC) Received: from MiWiFi-R3L-srv.redhat.com (ovpn-12-55.pek2.redhat.com [10.72.12.55]) by smtp.corp.redhat.com (Postfix) with ESMTP id B4D35492B0A; Fri, 24 Mar 2023 13:18:48 +0000 (UTC) From: Baoquan He <bhe@redhat.com> To: linux-kernel@vger.kernel.org Cc: catalin.marinas@arm.com, horms@kernel.org, thunder.leizhen@huawei.com, John.p.donnelly@oracle.com, will@kernel.org, kexec@lists.infradead.org, ardb@kernel.org, rppt@kernel.org, linux-arm-kernel@lists.infradead.org, Baoquan He <bhe@redhat.com> Subject: [PATCH 1/3] arm64: kdump : take off the protection on crashkernel memory region Date: Fri, 24 Mar 2023 21:18:36 +0800 Message-Id: <20230324131838.409996-2-bhe@redhat.com> In-Reply-To: <20230324131838.409996-1-bhe@redhat.com> References: <20230324131838.409996-1-bhe@redhat.com> MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761255719957201954?= X-GMAIL-MSGID: =?utf-8?q?1761255855256590904?= |
Series |
arm64: kdump : take off the protection on crashkernel memory region
|
|
Commit Message
Baoquan He
March 24, 2023, 1:18 p.m. UTC
Problem:
=======
On arm64, block and section mapping is supported to build page tables.
However, currently it enforces to take base page mapping for the whole
linear mapping if CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabled and
crashkernel kernel parameter is set. This will cause longer time of the
linear mapping process during bootup and severe performance degradation
during running time.
Root cause:
==========
On arm64, crashkernel reservation relies on knowing the upper limit of
low memory zone because it needs to reserve memory in the zone so that
devices' DMA addressing in kdump kernel can be satisfied. However, the
upper limit of low memory on arm64 is variant. And the upper limit can
only be decided late till bootmem_init() is called [1].
And we need to map the crashkernel region with base page granularity when
doing linear mapping, because kdump needs to protect the crashkernel region
via set_memory_valid(,0) after kdump kernel loading. However, arm64 doesn't
support well on splitting the built block or section mapping due to some
cpu reststriction [2]. And unfortunately, the linear mapping is done before
bootmem_init().
To resolve the above conflict on arm64, the compromise is enforcing to
take base page mapping for the entire linear mapping if crashkernel is
set, and CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabed. Hence
performance is sacrificed.
Solution:
=========
Comparing with the base page mapping for the whole linear region, it's
better to take off the protection on crashkernel memory region for the
time being because the anticipated stamping on crashkernel memory region
could only happen in a chance in one million, while the base page mapping
for the whole linear region is mitigating arm64 systems with crashkernel
set always.
[1]
https://lore.kernel.org/all/YrIIJkhKWSuAqkCx@arm.com/T/#u
[2]
https://lore.kernel.org/linux-arm-kernel/20190911182546.17094-1-nsaenzjulienne@suse.de/T/
Signed-off-by: Baoquan He <bhe@redhat.com>
---
arch/arm64/include/asm/kexec.h | 6 ------
arch/arm64/kernel/machine_kexec.c | 20 --------------------
2 files changed, 26 deletions(-)
Comments
On 2023/3/24 21:18, Baoquan He wrote: > Problem: > ======= > On arm64, block and section mapping is supported to build page tables. > However, currently it enforces to take base page mapping for the whole > linear mapping if CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabled and > crashkernel kernel parameter is set. This will cause longer time of the > linear mapping process during bootup and severe performance degradation > during running time. > > Root cause: > ========== > On arm64, crashkernel reservation relies on knowing the upper limit of > low memory zone because it needs to reserve memory in the zone so that > devices' DMA addressing in kdump kernel can be satisfied. However, the > upper limit of low memory on arm64 is variant. And the upper limit can > only be decided late till bootmem_init() is called [1]. > > And we need to map the crashkernel region with base page granularity when > doing linear mapping, because kdump needs to protect the crashkernel region > via set_memory_valid(,0) after kdump kernel loading. However, arm64 doesn't > support well on splitting the built block or section mapping due to some > cpu reststriction [2]. And unfortunately, the linear mapping is done before > bootmem_init(). > > To resolve the above conflict on arm64, the compromise is enforcing to > take base page mapping for the entire linear mapping if crashkernel is > set, and CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabed. Hence > performance is sacrificed. > > Solution: > ========= > Comparing with the base page mapping for the whole linear region, it's > better to take off the protection on crashkernel memory region for the > time being because the anticipated stamping on crashkernel memory region > could only happen in a chance in one million, while the base page mapping > for the whole linear region is mitigating arm64 systems with crashkernel > set always. > > [1] > https://lore.kernel.org/all/YrIIJkhKWSuAqkCx@arm.com/T/#u > > [2] > https://lore.kernel.org/linux-arm-kernel/20190911182546.17094-1-nsaenzjulienne@suse.de/T/ > > Signed-off-by: Baoquan He <bhe@redhat.com> > --- > arch/arm64/include/asm/kexec.h | 6 ------ > arch/arm64/kernel/machine_kexec.c | 20 -------------------- > 2 files changed, 26 deletions(-) > > diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h > index 559bfae26715..9ac9572a3bbe 100644 > --- a/arch/arm64/include/asm/kexec.h > +++ b/arch/arm64/include/asm/kexec.h > @@ -102,12 +102,6 @@ void cpu_soft_restart(unsigned long el2_switch, unsigned long entry, > > int machine_kexec_post_load(struct kimage *image); > #define machine_kexec_post_load machine_kexec_post_load > - > -void arch_kexec_protect_crashkres(void); > -#define arch_kexec_protect_crashkres arch_kexec_protect_crashkres > - > -void arch_kexec_unprotect_crashkres(void); > -#define arch_kexec_unprotect_crashkres arch_kexec_unprotect_crashkres > #endif > > #define ARCH_HAS_KIMAGE_ARCH > diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c > index ce3d40120f72..22da7fc1ff50 100644 > --- a/arch/arm64/kernel/machine_kexec.c > +++ b/arch/arm64/kernel/machine_kexec.c > @@ -268,26 +268,6 @@ void machine_crash_shutdown(struct pt_regs *regs) > pr_info("Starting crashdump kernel...\n"); > } > > -void arch_kexec_protect_crashkres(void) > -{ > - int i; > - > - for (i = 0; i < kexec_crash_image->nr_segments; i++) > - set_memory_valid( > - __phys_to_virt(kexec_crash_image->segment[i].mem), > - kexec_crash_image->segment[i].memsz >> PAGE_SHIFT, 0); > -} > - > -void arch_kexec_unprotect_crashkres(void) > -{ > - int i; > - > - for (i = 0; i < kexec_crash_image->nr_segments; i++) > - set_memory_valid( > - __phys_to_virt(kexec_crash_image->segment[i].mem), > - kexec_crash_image->segment[i].memsz >> PAGE_SHIFT, 1); > -} > - > #ifdef CONFIG_HIBERNATION > /* > * To preserve the crash dump kernel image, the relevant memory segments > Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com>
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h index 559bfae26715..9ac9572a3bbe 100644 --- a/arch/arm64/include/asm/kexec.h +++ b/arch/arm64/include/asm/kexec.h @@ -102,12 +102,6 @@ void cpu_soft_restart(unsigned long el2_switch, unsigned long entry, int machine_kexec_post_load(struct kimage *image); #define machine_kexec_post_load machine_kexec_post_load - -void arch_kexec_protect_crashkres(void); -#define arch_kexec_protect_crashkres arch_kexec_protect_crashkres - -void arch_kexec_unprotect_crashkres(void); -#define arch_kexec_unprotect_crashkres arch_kexec_unprotect_crashkres #endif #define ARCH_HAS_KIMAGE_ARCH diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c index ce3d40120f72..22da7fc1ff50 100644 --- a/arch/arm64/kernel/machine_kexec.c +++ b/arch/arm64/kernel/machine_kexec.c @@ -268,26 +268,6 @@ void machine_crash_shutdown(struct pt_regs *regs) pr_info("Starting crashdump kernel...\n"); } -void arch_kexec_protect_crashkres(void) -{ - int i; - - for (i = 0; i < kexec_crash_image->nr_segments; i++) - set_memory_valid( - __phys_to_virt(kexec_crash_image->segment[i].mem), - kexec_crash_image->segment[i].memsz >> PAGE_SHIFT, 0); -} - -void arch_kexec_unprotect_crashkres(void) -{ - int i; - - for (i = 0; i < kexec_crash_image->nr_segments; i++) - set_memory_valid( - __phys_to_virt(kexec_crash_image->segment[i].mem), - kexec_crash_image->segment[i].memsz >> PAGE_SHIFT, 1); -} - #ifdef CONFIG_HIBERNATION /* * To preserve the crash dump kernel image, the relevant memory segments