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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 2149AC432BE for ; Thu, 26 Aug 2021 15:04:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5D4B561026 for ; Thu, 26 Aug 2021 15:04:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5D4B561026 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=soleen.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 79C808D0002; Thu, 26 Aug 2021 11:04:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74C0A8D0001; Thu, 26 Aug 2021 11:04:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63BC18D0002; Thu, 26 Aug 2021 11:04:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) by kanga.kvack.org (Postfix) with ESMTP id 4A26B8D0001 for ; Thu, 26 Aug 2021 11:04:00 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id D88B31811CE2B for ; Thu, 26 Aug 2021 15:03:59 +0000 (UTC) X-FDA: 78517551798.08.D5C3672 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf09.hostedemail.com (Postfix) with ESMTP id 79F92300010D for ; Thu, 26 Aug 2021 15:03:59 +0000 (UTC) Received: by mail-ed1-f52.google.com with SMTP id q17so5167610edv.2 for ; Thu, 26 Aug 2021 08:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OwtqZp7lWqd2vwEBK7L5PvPKeHrWj5OjXlmVatWvPOM=; b=cNWIagbUZDoFGnXK7TtDjGs9zO7JRumnGFIPd880wcM4Lvs6RPsj+bHXbynR2FLa0X x1bL5HtOTYZijAnIH/6ywH6XCLZIYuVHiVKHgL8uV7hixXMhPx2MbkHIqso152OXUN3Q 6Zh+PEZ1u0JcITJTyu4hlhzcRIhBxcMsAmksU28urSX1hsx15rMzK3U5oS0FHco+hgR5 cX4Pm8kPJuEnSC8lm3T3kI/JCaUsxRSv0aQzAZHsmowT3BW4TJQdb8HY7Otasb9x74HZ PRSGndcCY/06Q5YOLjXHBErcF5iJgtKDtEDDNRc181FuDX8WyOYU5Zn2xRnahg2B5p3A bsOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OwtqZp7lWqd2vwEBK7L5PvPKeHrWj5OjXlmVatWvPOM=; b=gQNJx1B7ORuDkfkIDdMZSKrRXDrlMMVxWhcqblSZwwwYVGlFn++9P+ayIhHhA+tdfT kZ6M3O37C7LJ4BWiNBwWi8aBbiFr10iGPjSx6y+LYRJR0/DN8jhAnMouMEY8ECVeXQCu a/a3McnpuCtfXWSn6NmlcMfuw6NUOMn2ip7txIBMj2UKOfkRCu8MPZMs77510QjTTCun Qh7lH7GrbImPsnwlNlqYrkpFbdkZqVM2l0FzvLHXmIsfSclBp3tXUCvBzc8zSCZan9MM BEET+mzxXo8PVlWLN5iCvfPngKOOgkV6h0L0o2Vm/PgNkYx1G3zR6kbqdK+4+Qk9WuCS 7KZA== X-Gm-Message-State: AOAM530sslNfBq5Mzlk2nCNW3M0AICeaKvttJM/78+u/qf9a/wRT78zW IxoTtXkD4RxFP38HMhAPY3tbLf1rc4zjj+zthCi7PP+a0B7OVw== X-Google-Smtp-Source: ABdhPJxANtB4gX1t0qr2yCN+wvu9UWxcg8PM/6H9AVoTinfsvI1BNU9GqgvyCPlc5cLOm7EqXa/VMVpYynzX1MANJSI= X-Received: by 2002:a05:6402:34d5:: with SMTP id w21mr4858514edc.210.1629990238081; Thu, 26 Aug 2021 08:03:58 -0700 (PDT) MIME-Version: 1.0 References: <20210802215408.804942-1-pasha.tatashin@soleen.com> <20210824180555.GD623@arm.com> In-Reply-To: <20210824180555.GD623@arm.com> From: Pavel Tatashin Date: Thu, 26 Aug 2021 11:03:21 -0400 Message-ID: Subject: Re: [PATCH v16 00/15] arm64: MMU enabled kexec relocation To: Catalin Marinas Cc: James Morris , Sasha Levin , "Eric W. Biederman" , kexec mailing list , LKML , Jonathan Corbet , Will Deacon , Linux ARM , Marc Zyngier , James Morse , Vladimir Murzin , Matthias Brugger , linux-mm , Mark Rutland , steve.capper@arm.com, rfontana@redhat.com, Thomas Gleixner , Selin Dag , Tyler Hicks , Pingfan Liu , Andrew Morton , madvenka@linux.microsoft.com Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=cNWIagbU; dmarc=none; spf=pass (imf09.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 79F92300010D X-Stat-Signature: otn6t7szcf6bs4mn9ydydmi6yr17o145 X-HE-Tag: 1629990239-723502 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: On Tue, Aug 24, 2021 at 2:06 PM Catalin Marinas wrote: > > Hi Pavel, > > This series is still missing reviews from those who understand kexec > better than me. Hi Catalin, Yes, I am looking for reviewers. > > 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. Because kdump does not need relocation, we do not reserve pages for the page table in the kdump reboot case. In fact, with this series, kdump reboot becomes more straightforward as we skip the relocation function entirely, and jump directly into the crash kernel (or purgatory if kexec tools loaded them). > > - What happens if trans_pgd_create_copy() fails to allocate memory. Does > it fall back to an MMU-off relocation? In case we are so low on memory that trans_pgd_create_copy() fails to allocate the linear map that uses the large pages (the size of the page table is tiny) the kexec fails during kexec load time (not during reboot time), as out of memory. The MMU enabled kexec reboot is always on, and we should not have several ways to do kexec reboot as it makes the kexec reboot unpredictable in terms of performance, and also prone to bugs by having a common MMU enabled path and less common path when we are low on memory which is never tested. > > And I presume this series does not introduce any changes to the kexec > tools ABI. Correct. Thanks for taking a look at this series. Pasha