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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C05FCC432BE for ; Tue, 24 Aug 2021 18:06:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 39038611AF for ; Tue, 24 Aug 2021 18:06:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 39038611AF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 98D3C6B006C; Tue, 24 Aug 2021 14:06:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 93D3B6B0071; Tue, 24 Aug 2021 14:06:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 82C526B0072; Tue, 24 Aug 2021 14:06:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id 66DBF6B006C for ; Tue, 24 Aug 2021 14:06:05 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id D58D8181AEF3E for ; Tue, 24 Aug 2021 18:06:04 +0000 (UTC) X-FDA: 78510753048.33.6C3BA5C Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf07.hostedemail.com (Postfix) with ESMTP id 96A5A10000B4 for ; Tue, 24 Aug 2021 18:06:04 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id C6253610F8; Tue, 24 Aug 2021 18:05:58 +0000 (UTC) Date: Tue, 24 Aug 2021 19:05:56 +0100 From: Catalin Marinas To: Pavel Tatashin Cc: jmorris@namei.org, sashal@kernel.org, ebiederm@xmission.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, corbet@lwn.net, will@kernel.org, linux-arm-kernel@lists.infradead.org, maz@kernel.org, james.morse@arm.com, vladimir.murzin@arm.com, matthias.bgg@gmail.com, linux-mm@kvack.org, mark.rutland@arm.com, steve.capper@arm.com, rfontana@redhat.com, tglx@linutronix.de, selindag@gmail.com, tyhicks@linux.microsoft.com, kernelfans@gmail.com, akpm@linux-foundation.org, madvenka@linux.microsoft.com Subject: Re: [PATCH v16 00/15] arm64: MMU enabled kexec relocation Message-ID: <20210824180555.GD623@arm.com> References: <20210802215408.804942-1-pasha.tatashin@soleen.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210802215408.804942-1-pasha.tatashin@soleen.com> User-Agent: Mutt/1.10.1 (2018-07-13) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf07.hostedemail.com: domain of cmarinas@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=cmarinas@kernel.org X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 96A5A10000B4 X-Stat-Signature: 7njntbxihdt34i39g465j5bf1scmwdhb X-HE-Tag: 1629828364-835419 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Pavel, This series is still missing reviews from those who understand kexec better than me. On Mon, Aug 02, 2021 at 05:53:53PM -0400, Pavel Tatashin wrote: > Enable MMU during kexec relocation in order to improve reboot performance. > > If kexec functionality is used for a fast system update, with a minimal > downtime, the relocation of kernel + initramfs takes a significant portion > of reboot. > > The reason for slow relocation is because it is done without MMU, and thus > not benefiting from D-Cache. The performance improvements are indeed significant on some platforms (going from 7s to ~40ms), so I think the merging the series is worth it. Some general questions so I better understand the impact: - Is the kdump path affected in any way? IIUC that doesn't need any relocation but we should also make sure we don't create the additional page table unnecessarily (should keep as much memory intact as possible). Maybe that's already handled. - What happens if trans_pgd_create_copy() fails to allocate memory. Does it fall back to an MMU-off relocation? And I presume this series does not introduce any changes to the kexec tools ABI. Thanks. -- Catalin