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 58774C4320E for ; Thu, 26 Aug 2021 15:04:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 401BA61037 for ; Thu, 26 Aug 2021 15:04:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242892AbhHZPEt (ORCPT ); Thu, 26 Aug 2021 11:04:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39806 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231793AbhHZPEr (ORCPT ); Thu, 26 Aug 2021 11:04:47 -0400 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8D3F6C061757 for ; Thu, 26 Aug 2021 08:03:59 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id r19so5070017eds.13 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=IG4iR0GZZc9m+pbURqk5bcEvTAirxKh6dv37IJmUattI2oUrMvWDTrqjffi6mBDZ+O qdbFjsNXGPsgB4p5hRGiFEceg1eLo1wfJhjNL+oVVzQxRssMoA8cvhfdeeal7P2Sp15z rIyeu6N07UfqPYmq6bODaXlggzwmmopPOt+fpVIEOzPeVJa4t/nRXppXcF7cqaHx3CHL lNPe+d4HQ14iFx+aL+dTCyXiDOwfEF2/x8TuZgdp8IeCQA2EcC0We59hHrQqar/2BohR 4pS5Pnrj5ZK2SuNrpE19RWQIHFrtGi/vMcl08FJhiZUFpH1EyxWgMbh/8h8nUXmCx4Cz oZYg== X-Gm-Message-State: AOAM5327W2gjJkywnX9PiyeO7lQ22E6n2LqXcoIUt8adP+/rHcPrmCl3 WmnT3h4RIEsTbXDM9OLCdS+Cfi2RkzKr1aOtijLGDw== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 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=-4.5 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 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 6A424C432BE for ; Thu, 26 Aug 2021 15:06:24 +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 2CC5260F44 for ; Thu, 26 Aug 2021 15:06:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2CC5260F44 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=soleen.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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=e+xBAzywoGCLjr6B68P8bElqCC5ZTbC3exrMHZ9H+wg=; b=qGvuYFZI/lNCIf +7Gd7Qo/ez8bl8QIuVETWg0OkScrGjJQMCKoq2PVppI7O6zXxdg8YzchjDPFFvp7gZ0o5lBSmcMRE OR5+8kL7guNA5MKC91TQDyNEPWWN8VznSL7xrledhuWiGhquRunFBU58OjNtPWUjAtXQToX02bbFR eoO1pyCN/WQoo7MPDWR7u1LCJtTD6YRRErGpQhjk+PjDz8vtIr02A554AcWalUEfZK318WmA1bfof sDaMJ2KPfZEovX6+BkLNClL6QK4bi+AAZT4egTlENuBKl9gZB1bp0YBmKYdXVA2BEQtkpRsfACuE7 52wnTHE6ZlunAK17LERA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mJGvH-00ARRP-Fk; Thu, 26 Aug 2021 15:04:07 +0000 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mJGvB-00AROm-Jf for linux-arm-kernel@lists.infradead.org; Thu, 26 Aug 2021 15:04:05 +0000 Received: by mail-ed1-x536.google.com with SMTP id dm15so5100470edb.10 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=eZxJmUlu5XkfzC6BedeGXnOP8V16TCqNulL8WhL8mNaV6wMzj+0/X2qDFAgnPikluv KnM/yE01ZgigYZMXsdX0m7WqJ+Uh75ZDXgx30ECRP6gTdIGCCNIh/h0dADfJ6t+9mfBg aef+Pyw1SsSpUi4lI0r2oDwQQ5/6jWoQwtTBLFGduP96XxPsEbveguf0KXMOUdSYKEO5 4Nu9/MhotEO5wn4P10UxxJZa/2d0fI902TBW575kAxlrLDSHzBGN8/U8qnD1wLubIlP2 crGhetnnDRr81NnNahtsg7oJWvx+EpdjJpKulQzRGt7eYgOXeJRqGVkaC5hvtu0FiK8r NCiQ== X-Gm-Message-State: AOAM531TGimgmWx8yf9qrbMN2XYOZmVJvLaut6wkb3hBYBdoSegYueO7 +lOwcPjt50AsCYE3TS6eAM+vvFi1vcYxgfitwfNMPg== 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210826_080401_852774_C72ACE09 X-CRM114-Status: GOOD ( 28.02 ) 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 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 _______________________________________________ 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: Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mJGvB-00AROl-I1 for kexec@lists.infradead.org; Thu, 26 Aug 2021 15:04:05 +0000 Received: by mail-ed1-x52a.google.com with SMTP id s25so5206192edw.0 for ; Thu, 26 Aug 2021 08:03:59 -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 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: 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 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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec