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 3578BC678DC for ; Wed, 11 Jun 2025 13:38:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B61A46B00B7; Wed, 11 Jun 2025 09:38:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B3A336B00B8; Wed, 11 Jun 2025 09:38:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A77EC6B00B9; Wed, 11 Jun 2025 09:38:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8A3246B00B7 for ; Wed, 11 Jun 2025 09:38:46 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 426F3C0D17 for ; Wed, 11 Jun 2025 13:38:46 +0000 (UTC) X-FDA: 83543225052.12.D1CE9F1 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf20.hostedemail.com (Postfix) with ESMTP id 628591C0002 for ; Wed, 11 Jun 2025 13:38:44 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="H3/0dNW+"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of pratyush@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=pratyush@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749649124; 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=ccGrVDJ+WUSoLiOk5obSbpSOZ6sdQYkWk94+LyD+iS8=; b=Nvg9OJoOCSKTikda2G10TNQ2ljDi3bCrW4IyFOz7iv2pkqnBD9fCFuQC/Cj7/+mTKFDpo6 exaGM8+6BEd6URdQ91+zkyYAF058v23DDV8SdecjGJewlgNrvrYt7iy1GiJm2p3ypKRkHG P7nHX0c2w4IygSfCdm1ay2NrgRfyWuE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749649124; a=rsa-sha256; cv=none; b=OZvzoMBLED+CLhiGZvnB473fy4GBdsujd90UDxOOv1HZKt076v+FmUBj22GfRnuYMftsYx ms6o/QFnRpFX5CLxlmhlU+HqcPQy3ibG8fQjtGx8qSbsJuIZZq0wpMlaqQwRz+atL/oKz5 XHzaMwB+s2No1OOGnOsbPIu1cvlkJa8= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="H3/0dNW+"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of pratyush@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=pratyush@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 1AA824499E; Wed, 11 Jun 2025 13:38:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B8E5C4CEEE; Wed, 11 Jun 2025 13:38:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749649123; bh=ApP+He8rbDgY3eull1tpS3JNL84wa6c46rgsr+2B2rI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=H3/0dNW+kMGwcGMHzgalbsTXgIMCO2rpJ0js9L+r0AThN/s0Eyx4qH+i17Kd4dl3F qxBriuvT1ZnnD00+VWINeYWuC3MtvOwVf2fxao9E6cps2zCYCB/h4MXBozMab3NUEy uHKXJKjo3HPfm+dOf1Rb4cjsWvIK29aW5bR+pjLvMZv+iSL6871EgZj1odwsQnbUOM AJbYohWEZceQJotFEgGY8JrKBTx8UeaYh8Q51p+FJ7c6P1E/cw0dJCNHsyqQVsMYaJ Knk1gpQRSORDWJPwkkVDgYME3NsaVSNIwK2K6TUzcKHlFCtzKGOzPEz/2scBaHfqpd gn/6dHrCoAAAQ== From: Pratyush Yadav To: Pasha Tatashin Cc: Pratyush Yadav , Mike Rapoport , Alexander Graf , Changyuan Lyu , Andrew Morton , Baoquan He , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Clapinski Subject: Re: [PATCH] kho: initialize tail pages for higher order folios properly In-Reply-To: References: <20250605171143.76963-1-pratyush@kernel.org> Date: Wed, 11 Jun 2025 15:38:40 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Stat-Signature: sm3o4hwz8en575off13r6tj171epp4zm X-Rspamd-Queue-Id: 628591C0002 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1749649124-42143 X-HE-Meta: U2FsdGVkX19cajonnSeWMvPpLOnH5HcBvA6CSjbbzFzFlGus2Nm3FewSs87CEltnyi/BwokHgaKJtKTvew49o9qmychozG6oyTb6d6JsI4nLkw2RJhV0OPduzEMQtQHSdoQQDlQOolVXEmEEshgDU5ADmcRkMBaHVEa9mjq2JVEkIrWBhfmjdEjUL1EZHgKtDX6m4EB4FKEjECQ20xNe9+zW1uzd7XYzd45+IKF7GbDChwG3q8ZD28A7DrsWKx8MGAZo0RoJtJFrzD4PeRmhpHmO1lqFUNOV1si1FSZ03qq30fEtZrsYrEo/46KvH9+KKPyrEuvZMJje+lwed/pLXNtoJoJTTPVHaAMJ8V4jj4OfvKUu2iB7o8sRwkcFa0cb7WdQTwNj8bWatk0sgPIdgZPP2XhnWfYADoSLSdbOXJeg675K98PEa9EzH+e2Q64C+sPJ5hSky5xYgqnFfczGeM3jWHRwCENJ/PXgeekS6u+KuQTnkxIH1ju6ViGq9WKIcK/MFHmM1OrJ+bZ9zqitp9x9ZXkZIapBO4QM9vMzu/KGh20obYWw5XHBwJVokbwfjHZCVzNuw7i4sgGlGB774XoehxFC+y+eiaIyoBfW1xU6mF+uYW/Brv8ZEEnOmgcMd3OAO9vX+6W8mSNN1Lg756GLXtyLPhfMXGj8dTqm3Y6bJmsjvmpE/IyRY3RblLxLNHhH8hsOOauVfsXIcD2GrjdaTApZ5vGZGns9D+PLjox8s0uuagXtCcxIAgB1nWwGEHpiJjGOQgvW7pJuUcs4b2VOHNS2Pi8gv+uMrmF+UcwQXtQGgcXOjh5vSq/FhJiXC3xbx7gGbonWV2PVD/C+F/qF2G4C1mXfn5BVB4e5kUaeyWn1X29J5T/V8O4oNA1uZgOBnXCv5VkIj8d9T1t13RbQBBvq2GTxPJi6w8qNXadnEncCTo6MpsYxSbeUBgtaIOLCdWsjNTLx44QzYJG oh3yYywo WiEJ9aNR4uhU2TcGV7SS8xgYA1Jm/qrOICoWjf7Xk02NOJ85ZTDqQDOGN93PYwV10LHN634Dyfd8qfPUs0ejIbp8NzZIjh77DkI0mA1aJFSrXQ4kgIe0U8SlxSDUrzMjaubewC52b536j95QmHip+SnVcsr9zrqD6qTKunNYuspdg4tan8oBWYjDnahfpZa9//MwwAxfvITLe60Qb29iPAU3CZJbOkHx2GKXMNQ9a5L8TtGq9jexwaD9Q4g== 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 Wed, Jun 11 2025, Pasha Tatashin wrote: > On Wed, Jun 11, 2025 at 9:06=E2=80=AFAM Pratyush Yadav wrote: >> >> On Tue, Jun 10 2025, Pasha Tatashin wrote: [...] >> >> > > We could, but with that would mean we'll run this before SMP and = it's not >> >> > > desirable. Also, init_deferred_page() for a random page requires >> >> > >> >> > We already run KHO init before smp_init: >> >> > start_kernel() -> mm_core_init() -> kho_memory_init() -> >> >> > kho_restore_folio() -> struct pages must be already initialized her= e! >> >> > >> >> > While deferred struct pages are initialized: >> >> > start_kernel() -> rest_init() -> kernel_init() -> >> >> > kernel_init_freeable() -> page_alloc_init_late() -> >> >> > deferred_init_memmap() >> >> > >> >> > If the number of preserved pages that is needed during early boot is >> >> > relatively small, that it should not be an issue to pre-initialize >> >> > struct pages for them before deferred struct pages are initialized.= We >> >> > already pre-initialize some "struct pages" that are needed during >> >> > early boot before the reset are initialized, see deferred_grow_zone= () >> >> >> >> deferred_grow_zone() takes a chunk in the beginning of uninitialized = range, >> >> with kho we are talking about some random pages. If we preinit them e= arly, >> >> deferred_init_memmap() will overwrite them. >> > >> > Yes, this is why I am saying that we would need to skip the KHO >> > initialized "struct pages" somehow during deferred initialization. If >> > we create an ordered by PFN list of early-initialized KHO struct >> > pages, skipping during deferred initialization could be done >> > efficiently. >> >> Or keep things simple and don't use any KHO struct pages during early >> init. You can access the page itself, just don't use its struct page. >> >> Currently the only user of kho_restore_folio() during init is >> kho_memory_init(). The FDT is accessed by doing >> phys_to_virt(kho_in.fdt_phys) anyway, so there is really no need for >> restoring the folio so early. It can be done later, for example when LUO >> does the finish event, to clean up and free the folio. > > Good suggestion, however, KHO does not have any sophisticated users > that we are going to be adding as part of the live update work in the > future: IR, KVM, early VCPU threads, and so on. So, while today, this > might work, in the future, I am not sure if we should expect struct > pages are not accessed until after deferred initialization or simply > fix it once and for all. Right. We might end up needing it down the line. But from a quick look, it doesn't seem to be trivial to solve, so IMO we should solve it when those use cases actually show up, and keep things simple for now. --=20 Regards, Pratyush Yadav