From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Date: Tue, 24 Aug 2021 19:05:56 +0100 From: Catalin Marinas 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-Disposition: inline In-Reply-To: <20210802215408.804942-1-pasha.tatashin@soleen.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org 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 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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec 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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 38AF4C4338F for ; Tue, 24 Aug 2021 18:08:05 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id EDFAB6113A for ; Tue, 24 Aug 2021 18:08:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EDFAB6113A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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=3gPrAS0skpFdTLADP1kvU9XHjhNkWtQQ+n7t2Y+7is0=; b=gCWMua8T0XnulH xrDXVzBnlrLjHQ5ZJUuLSa4QSRGdLDpIJXKe8xOOMrHxaznYNUVmR7rLBsUhwR+eNuW5hyvji1aN5 wpog0afEjGHR45b/KgIQhlfStaaARoPpTxdsFNL5B/vFvQV9SDCLvlYiPgyK2bLkHhK1lQb8CSS9b +irKb5vPG8hJypfqACj2NMzVvdIAc3MvNlCaxPdWSTpLyN/l2s3XR+Z59RF2LWqLyg2HvhfWwlB6F fpyVE+tCz3hfA/hWxnVQ1OPmxDAPs3h+3G/PezHx9jnK8E2uFJFfxgoYZ5O7DaLraHUCkP1y2B3c1 NSormd5qWT22LxGt0apQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIaos-004K0u-88; Tue, 24 Aug 2021 18:06:42 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIaoO-004Jsq-N7; Tue, 24 Aug 2021 18:06:16 +0000 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-Disposition: inline In-Reply-To: <20210802215408.804942-1-pasha.tatashin@soleen.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210824_110612_809088_10B3FA42 X-CRM114-Status: GOOD ( 12.95 ) 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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