Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp2942700pxb; Tue, 24 Aug 2021 11:06:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxZX+270gQV7SETpas68Exc8gLQW44Bqjak8kMzdhpAGpNGTqjTffgQn3JnDNesJgLDo6v X-Received: by 2002:a92:c26f:: with SMTP id h15mr21877245ild.47.1629828417479; Tue, 24 Aug 2021 11:06:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629828417; cv=none; d=google.com; s=arc-20160816; b=IsYMdnyGatA7BWI3iAAJzxnBcxNq/faehQogX6Br69urRXzJDvnn4sEN/Ex9tg0u0/ sW6Y64WgmuL0tD58rtriKJN8/wNQrLXWqlTW0iwntC2IPyUrigDkwKQIvMwgYKdBR95x E9iRR6c6YEenbIXBa+4lK/mkurVN5Wu3R9PX7yRmOzBtmA1xL6+p/5Oxp5twFlOkWyLy 5EViUUiQPSRE3og3VTiPKo3+9kZCLUlHoEkjB+5GJ7RuOYdUrz5nYLMeiJ6tQOTwYcTK tg3Gze3CBcAokHrAvRmlCNBjkuPnIwrNPIEiCpnyyK3sTKsaEd1PzDYh0zUbLs61Ztao fo/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=6CPS9bixM05DqeSVRTfYemUMUCca6K5gNo4OPkW/83k=; b=wdS0kl6Fo0iAymDgK8sy23yWRpef5X6bkTEjDc3e9BKPLwC0FjIpX0m9EDfG5Wpqq+ rL67+yrVe5eFDTLOcGdmXxSrXjMwDLC2bh2rDfGN6wVPU8gIv6ifBV09XcUnbxllB9DH WtMxKNe+tCmGPrVhbNKfg1TF0NP/B0exEPV3v61TBu2gMzTzUy6dRJOZz31AwT6JcisZ 9rlKXe6SAU1pofzTXBANfQU7M7KFMVxEzfU2saHZgZEaghlwDIixvm3L1Or7XzmYy+0R r2JVSSap6BGUo5hXn99Da3ENQv3fQEAXPgCfEDMvM6bnNLvgH64w8zPLwIhVieMyFkU+ Lodg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o3si19211880jah.81.2021.08.24.11.06.44; Tue, 24 Aug 2021 11:06:57 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230440AbhHXSGr (ORCPT + 99 others); Tue, 24 Aug 2021 14:06:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:35528 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230344AbhHXSGq (ORCPT ); Tue, 24 Aug 2021 14:06:46 -0400 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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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