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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75A69C36005 for ; Tue, 25 Mar 2025 21:57:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63107280049; Tue, 25 Mar 2025 17:57:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E0A0280005; Tue, 25 Mar 2025 17:57:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 482BC280049; Tue, 25 Mar 2025 17:57:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2AB9B280005 for ; Tue, 25 Mar 2025 17:57:06 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 726251CB50B for ; Tue, 25 Mar 2025 21:57:07 +0000 (UTC) X-FDA: 83261434494.18.798DC9E Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf10.hostedemail.com (Postfix) with ESMTP id 7AE12C000E for ; Tue, 25 Mar 2025 21:57:05 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=SdF25tnG; spf=pass (imf10.hostedemail.com: domain of fvdl@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742939825; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HQ1y6K6+ej3yRZwY8vjRGO04KNMR+SXa0FKK7FdZ1GE=; b=b3eGoick0X7Qiwn95qLYlbB09YPfAfKhD/OuBovT4OeyKxlwBWSbXE6r84Vgxp3JaoypZg nKoUnDxQVyS298eCO8gZjCmQbaDf6OSCLStaNMLUqemgE6nNkxNgD+nh3+YPMt1YgD6pjc 8jKyOrgfO62xR52qTITuvM2ZNsMIxm8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742939825; a=rsa-sha256; cv=none; b=zQae+2eL9vvG9Lbxg7CBijtZrbraxFqJcKxDZzr8C0PedEKOpaLLmwaZg/eY4kz10nh7XX waVjHBg3E20Ov7IwDXBB4szAgmTYLSN65MLvXYmtaPuq9r8Nt/MK6CXsvnM7ES2ZsbBAM1 VpF15w6wUMJzv9N+KYVgWLG+bYuZadE= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=SdF25tnG; spf=pass (imf10.hostedemail.com: domain of fvdl@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-47666573242so158731cf.0 for ; Tue, 25 Mar 2025 14:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1742939825; x=1743544625; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HQ1y6K6+ej3yRZwY8vjRGO04KNMR+SXa0FKK7FdZ1GE=; b=SdF25tnGrNMXZIsJjxQ3S2M+wlhqs5L8gH8xCh0fayM2t2mRYUC8KDgoynx/Jt58rm rp+imXLWPLeV2b+TsSUmQarohmRuMsUKWtxkEBa8FagC+pDRf6Cb3mLm/Uvrn3SlhcVn 4jmeJSv+d1XSGOCpeaoR7T9lmjo66QZqf0A/2ZsIHkcQLTxpJBKpAOcvm8bj2LuxZeyV 4N+3ldR4CvxzBR7N2eWqBt7vsJ/0I29U7pmAEJidcLN7LZq2T550/yFTBVZVkLHjY57l JdqLiEuw3yr4abjT3myjPMAau1nJkgbYteHmnVVPbrFsvScy2JvEWiJgzSoBUeqhIuxN M3+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742939825; x=1743544625; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HQ1y6K6+ej3yRZwY8vjRGO04KNMR+SXa0FKK7FdZ1GE=; b=KKKxRlTuOb2xS17PVjDGP7b8WtcgAKPUltRHv3nmWta2rvb+yoClVWyOVt+czS7WLo 0Xv6johfDm7+wiJh0CjronkGxbnVsR5NWN6FasCDyKq6SbkAumnqqYnSjyFf8OIHWFAh 0QDfedXemcHwSQsFvB2MCXczOerdVQlZ9aY8Ubcy+orICfJTNi5AsH9WytkGDZCImWm+ 4KRjx4IYm99pUWdWnCLt4Z/LcY85YFq/wWjxT/MiTUva3ZZ+JShu/jg7IguscX0PTw6j N63Otbp+pBwhVSFXSjgEF73kU8hW6nXpjIqDbrW2s6JGCACZ9SgCF8t4sffeg1YKZbyd uJ9w== X-Forwarded-Encrypted: i=1; AJvYcCVPeZEoqt9mdgtIuyWtIsJnN7UtewHz44oZ0ac57VCCFNaCAJsIr9aZ7iSDCuOkkNEsJqEKsQ92xg==@kvack.org X-Gm-Message-State: AOJu0YxjCEZRjdbbw/inYXXBezEZofMtJ+wspPneg7keH4Cr5IUfs0hF L9jm2PzpTtAvHwq/u1/TA2wqAREwkTUjy77TSvyaD8dUk2lSIBslEdIgaOTme7pO3x8SZPlSXGE aPLPeUWNtuFC4LPtpkOnfXm6mPH6y298j7KYj X-Gm-Gg: ASbGncuCXzYAyHZGpa7oL0EvOIl3K+94QH5pnoN7nM5gzWPQ3qYjiritAonfv8AmAs1 z5qmS8F9avD7YmUkk42dOL1by/3KcJ73yj0AJFxHnvJQnV8QzjFpILM/Fs7OiRZhYOCyYTWS4Xr 1JKodhNdcTUnTYYCh/3pFQBAg= X-Google-Smtp-Source: AGHT+IH/hOP5cz4/f0sHk0CeJX9EkyXr4jUNyz2/3phYBrvYUFI/aeZIqxahOHueL/ItRZ16YGhpvWcqwmSbOB39SDQ= X-Received: by 2002:ac8:6f05:0:b0:472:61:652 with SMTP id d75a77b69052e-47762e3319amr159031cf.28.1742939824283; Tue, 25 Mar 2025 14:57:04 -0700 (PDT) MIME-Version: 1.0 References: <20250320015551.2157511-1-changyuanl@google.com> <20250320015551.2157511-8-changyuanl@google.com> In-Reply-To: From: Frank van der Linden Date: Tue, 25 Mar 2025 14:56:52 -0700 X-Gm-Features: AQ5f1JoGOY12Onu4tBrwgKWOKiM9GvbU7kfWg3JcOKhqducXkStWehGksThe0mY Message-ID: Subject: Re: [PATCH v5 07/16] kexec: add Kexec HandOver (KHO) generation helpers To: Mike Rapoport Cc: Changyuan Lyu , linux-kernel@vger.kernel.org, graf@amazon.com, akpm@linux-foundation.org, luto@kernel.org, anthony.yznaga@oracle.com, arnd@arndb.de, ashish.kalra@amd.com, benh@kernel.crashing.org, bp@alien8.de, catalin.marinas@arm.com, dave.hansen@linux.intel.com, dwmw2@infradead.org, ebiederm@xmission.com, mingo@redhat.com, jgowans@amazon.com, corbet@lwn.net, krzk@kernel.org, mark.rutland@arm.com, pbonzini@redhat.com, pasha.tatashin@soleen.com, hpa@zytor.com, peterz@infradead.org, ptyadav@amazon.de, robh+dt@kernel.org, robh@kernel.org, saravanak@google.com, skinsburskii@linux.microsoft.com, rostedt@goodmis.org, tglx@linutronix.de, thomas.lendacky@amd.com, usama.arif@bytedance.com, will@kernel.org, devicetree@vger.kernel.org, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 7AE12C000E X-Stat-Signature: iyrz81k147qx9tkc8a4rfi96r3r8j6bn X-HE-Tag: 1742939825-486535 X-HE-Meta: U2FsdGVkX1+/9TwV75wxttmJ4DrcUHfqucGknTuKGTgT/kY13AAe9g5cjCivpe0R1Cd2BP/u6AAATNHyhq1pZse7Zi9yLdVwIch0ERn7sDhLFG2anQb1y1L87t5lF3SA1SsSsx1lgVXKlBpaCMTznF6ae3aaDMxuodWCq+2i9KVeE/jhHZAAmDJLTHhy+z/VTtn73AvJ3G0wzjMh8rO3BWv12oqighMFPMjwcSVgUE+QC8dJ4yRqlBC66KqIVG89tka7A8FDEUgMkjV21WHycdzOiEH3irfoXTa9XW9EF/MRynmzssRitLA2RiE7OQBe1ebX1NXyeD/2y+mZ1r1s2tugjiiix2EsfUAStDRr6U0drmQpaA6vJhFU9V/4a+3U0bGZHgfUsuVw4V9j21DT7j6WqqZEgRJrMxq/d7UI+oaAzj/bDlmmuNnhyHpfrMQeymVDQumZKuE2TtXMvTEAcA5jjv9ngWv5k0AiC8ryh9O+amxSWx6+v5WZ3ygczvc7ksvq/b1iunAGWAmbXvQfdwPzwIoJYZpt+dCEEeW/diWWl6dVvUgSExsNt5RXAjgkUnLUkCqU/DTD4/FUTk51c9hgmpf0BUgpm1cz3rYgc3qWOOMbptRdvp49ww77/Jtx9XUtiI6mBbgjboK5t5nT688PZRYYDUT/Ckvgiie5H92Q8s/KQkAbNN+cya0sP+tK9xtSkD8cnThWO/fXWTfZEHCWTGCKKPRSJm8zuT4bEx01YfCBPlKPUkK/aqfkW6k76TzeBi66hEJYm830moGMct1cpHBASNYR/sMhd7qP88b2VLJ7IDCyisqFlQ/H8lK26qUkCxF1STGkZwIHmiaWeXCiLUh5+NuDfjFbdP/2ghON49WEC/7DqeG90+e5hYaCB9imw+CFatg07g3vO7ugAiUutI+Qbasuc8f19ac7b077SPYqfwjBVtcFsdMxMW6c2dyY6kKerRtIimSH3YH srqnbci1 wMq+ixPBBCGo3ZPHDqgVmCUoZeotZdXTPRBGrqD2t62oTXA2XwxwwCRLzJCDlgodlmvnLPA+93M19BJIHI7+QyRDak2PJoGW5BX4R+N7ILuw4gZRberBrQ3Hq1YgKrtC+uDe+UW2N+vR3fDFF/4A3zEsHS2WGgQwZy0vsA5kn1xZm98ZNwQtzfoz1zMSyP30qv/1uuQgj8ebTdcroO94xV6UGUqxQ9ynUcEHh0nBbUjVAZMzS5xROBsAqP4AmTTsyRGjqyoh8kSZChwbjxhQlto6R9x1/J2RWlUFyVblJ42O/lTU+fNjQWDZ8mBuTPqI1XkMTcp68U6rplDw= 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: List-Subscribe: List-Unsubscribe: On Tue, Mar 25, 2025 at 12:19=E2=80=AFPM Mike Rapoport wr= ote: > > On Mon, Mar 24, 2025 at 11:40:43AM -0700, Frank van der Linden wrote: [...] > > Thanks for the work on this. > > > > Obviously it needs to happen while memblock is still active - but why > > as close as possible to buddy initialization? > > One reason is to have all memblock allocations done to autoscale the > scratch area. Another reason is to keep memblock structures small as long > as possible as memblock_reserve()ing the preserved memory would quite > inflate them. > > And it's overall simpler if memblock only allocates from scratch rather > than doing some of early allocations from scratch and some elsewhere and > still making sure they avoid the preserved ranges. Ah, thanks, I see the argument for the scratch area sizing. > > > Ordering is always a sticky issue when it comes to doing things during > > boot, of course. In this case, I can see scenarios where code that > > runs a little earlier may want to use some preserved memory. The > > Can you elaborate about such scenarios? There has, for example, been some talk about making hugetlbfs persistent. You could have hugetlb_cma active. The hugetlb CMA areas are set up quite early, quite some time before KHO restores memory. So that would have to be changed somehow if the location of the KHO init call would remain as close as possible to buddy init as possible. I suspect there may be other uses. Although I suppose you could just look up the addresses and then reserve them yourself, you would just need the KHO FDT to be initialized. And you'd need to avoid the KHO bitmap deserialize trying to redo the ranges you've already done. > > > current requirement in the patch set seems to be "after sparse/page > > init", but I'm not sure why it needs to be as close as possibly to > > buddy init. > > Why would you say that sparse/page init would be a requirement here? At least in its current form, the KHO code expects vmemmap to be initialized, as it does its restore base on page structures, as deserialize_bitmap expects them. I think the use of the page->private field was discussed in a separate thread, I think. If that is done differently, it wouldn't rely on vmemmap being initialized. A few more things I've noticed (not sure if these were discussed before): * Should KHO depend on CONFIG_DEFERRED_STRUCT_PAGE_INIT? Essentially, marking memblock ranges as NOINIT doesn't work without DEFERRED_STRUCT_PAGE_INIT. Although, if the page->private use disappears, this wouldn't be an issue anymore. * As a future extension, it could be nice to store vmemmap init information in the KHO FDT. Then you can use that to init ranges in an optimized way (HVO hugetlb or DAX-style persisted ranges) straight away. - Frank > > - Frank > > -- > Sincerely yours, > Mike.