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=-2.3 required=3.0 tests=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 9883EC3A589 for ; Thu, 15 Aug 2019 18:11:26 +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 6B1B92064A for ; Thu, 15 Aug 2019 18:11:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="G04OgdAf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6B1B92064A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Fw47sGP0Nfyk7+LnyjYHyQXqm+xHeiaQNZCu9c9+qTQ=; b=G04OgdAfEDOaxu wNF6ZaGRMXOoxL86AzXN4DC8qcbUGO1EGgOntguMTDle3vnJ8zrxjrPrfLRkiMBnqW62eIJSNtrDy J3qUfX8I74bWWSH0IIeCc4VYMrV3bu21s22mK1UccmBsx+5XTwXFVZJxcdq2CnP8rj0AZfARe20yU j927cmVWgnagLfLGDU6KpVMNZmpext5MkH/hYyXXYxJeiE+pbIGF0kiaukzCHabyUNnxvEOAlCnZq KiFFYw8LlGGoKmWeggZh98Gy4KRHD9ggUT9Jq+2ytlNh3CwEuJhuyaPFGXLOL/4nIX8ww+tC1nIms XV42xVTyfSn8RqPyt89g==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hyKDd-00021f-Gz; Thu, 15 Aug 2019 18:11:25 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hyKDU-0001y8-PD; Thu, 15 Aug 2019 18:11:18 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D3CB928; Thu, 15 Aug 2019 11:11:13 -0700 (PDT) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1058F3F694; Thu, 15 Aug 2019 11:11:11 -0700 (PDT) Subject: Re: [PATCH v1 0/8] arm64: MMU enabled kexec relocation To: Pavel Tatashin References: <20190801152439.11363-1-pasha.tatashin@soleen.com> From: James Morse Message-ID: Date: Thu, 15 Aug 2019 19:11:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190815_111116_902114_41CAE525 X-CRM114-Status: GOOD ( 16.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sasha Levin , Vladimir Murzin , Jonathan Corbet , Marc Zyngier , Catalin Marinas , Bhupesh Sharma , kexec mailing list , LKML , James Morris , linux-mm , "Eric W. Biederman" , Matthias Brugger , will@kernel.org, Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Pavel, On 08/08/2019 19:44, Pavel Tatashin wrote: > Just a friendly reminder, please send your comments on this series. (Please don't top-post) > It's been a week since I sent out these patches, and no feedback yet. A week is not a lot of time, people are busy, go to conferences, some even dare to take holiday! > Also, I'd appreciate if anyone could test this series on vhe hardware > with vhe kernel, it does not look like QEMU can emulate it yet This locks up during resume from hibernate on my AMD Seattle, a regular v8.0 machine. Please try and build the series to reduce review time. What you have here is an all-new page-table generation API, which you switch hibernate and kexec too. This is effectively a new implementation of hibernate and kexec. There are three things here that need review. You have a regression in your all-new implementation of hibernate. It took six months (and lots of review) to get the existing code right, please don't rip it out if there is nothing wrong with it. Instead, please just move the hibernate copy_page_tables() code, and then wire kexec up. You shouldn't need to change anything in the copy_page_tables() code as the linear map is the same in both cases. It looks like you are creating the page tables just after the kexec:segments have been loaded. This will go horribly wrong if anything changes between then and kexec time. (e.g. memory you've got mapped gets hot-removed). This needs to be done as late as possible, so we don't waste memory, and the world can't change around us. Reboot notifiers run before kexec, can't we do the memory-allocation there? > On Thu, Aug 1, 2019 at 11:24 AM 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. >> >> Performance data >> ---------------- >> For this experiment, the size of kernel plus initramfs is small, only 25M. >> If initramfs was larger, than the improvements would be greater, as time >> spent in relocation is proportional to the size of relocation. >> >> Previously: >> kernel shutdown 0.022131328s >> relocation 0.440510736s >> kernel startup 0.294706768s >> >> Relocation was taking: 58.2% of reboot time >> >> Now: >> kernel shutdown 0.032066576s >> relocation 0.022158152s >> kernel startup 0.296055880s >> >> Now: Relocation takes 6.3% of reboot time >> >> Total reboot is x2.16 times faster. When I first saw these numbers they were ~'0.29s', which I wrongly assumed was 29 seconds. Savings in milliseconds, for _reboot_ is a hard sell. I'm hoping that on the machines that take minutes to kexec we'll get numbers that make this change more convincing. Thanks, James _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel