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 D1F2AC678DC for ; Wed, 11 Jun 2025 13:35:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 716546B00A7; Wed, 11 Jun 2025 09:35:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C6A16B00AC; Wed, 11 Jun 2025 09:35:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DCB16B00B7; Wed, 11 Jun 2025 09:35:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3E87D6B00A7 for ; Wed, 11 Jun 2025 09:35:54 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E35C75D4FB for ; Wed, 11 Jun 2025 13:35:53 +0000 (UTC) X-FDA: 83543217786.17.AB09166 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf07.hostedemail.com (Postfix) with ESMTP id 4004B40005 for ; Wed, 11 Jun 2025 13:35:52 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=a2b7VoG4; spf=pass (imf07.hostedemail.com: domain of rppt@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749648952; 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=/DVFZslNMDQCpFsrI22FsAPDdmwlVhjdsES7f27EQQ4=; b=0tyXefQzfiIHwJo77qroWxRJYPsphjPvkvygQQZQnTTPu3QY8757/kOCbgG6iELbeo7qJ7 butOzUYlnjgFiGNwFvoORi3rUi+KaWXAMbs+4HudPNsDIj66WR8lXGT49OA83xCfEfSW6O XTENjkq+SftifaOgn7olYtP/lRwxI6w= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=a2b7VoG4; spf=pass (imf07.hostedemail.com: domain of rppt@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749648952; a=rsa-sha256; cv=none; b=68WXikcqPY5247RIOzN2qCIaC8yiQ6OaXLtXjdNV60KrjKp9lPR9yuf7VIy3kGQhaCz+ED JHCg9tKon/s664Wx1Fx8imuAUsVtAsCPmmRq5LfWqnO62CbpNJpUJHqECFjJzt2MdqiWfv fi4q+zH2bbPF0Hf0HngcCByBNrVNRxY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 8EA11A51805; Wed, 11 Jun 2025 13:35:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01C02C4CEEE; Wed, 11 Jun 2025 13:35:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749648951; bh=8X+6Dpb2majUF6w6aZsaAegNKHMP2ANt2g25xsiSY54=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=a2b7VoG4KVqWAF+icCE2Z4hRUFIlu5OHHqYJ3oHZFr4R7WyyXukCtW9n+ox3tMs5a fBKESZmb07rlHHttjx1F4xhBLi+GI/wjGbkMeDrKI9rhP6MkomwzA7VRwrN/QQAcTB 18NWQhj68drd91qGaVTUU24Kd4QLQ0SSQPFgT1cJ6yKyOWVUVLiCOwjzZHfDwrTaDu GGefcMkhiQ048C3/8M4NKoKylVohrYJ0mtxNcWkUhJ18XM6qc+9JDpkMF3+lcZz1Wx rGza2+RMTw7fo4GZRCPMqNE5CyCp3I5GFLIh/OIOpSRTDapMEIYZYTexFKBFUE205v 1d6RTTMYa8e0A== Date: Wed, 11 Jun 2025 16:35:44 +0300 From: Mike Rapoport To: Pasha Tatashin Cc: Pratyush Yadav , 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 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4004B40005 X-Rspamd-Server: rspam03 X-Rspam-User: X-Stat-Signature: 5fuw45e1w44ew33kuucktbw6uj8d5gka X-HE-Tag: 1749648952-309640 X-HE-Meta: U2FsdGVkX1/IaDhUDU5fdm5qQ0K4ya2wHRuJJ719IqM3IDAQ62Vn/Nlzkx9cQv1si0st6Y2eKzQ8MPWkCvZ1nUiE2aXih9RqBk1PBDlNDNCY4L+hE7Rh6JHeyEC5qLx0SD2b4eJ3iFYmBB+9SK3mrWgRHEtOxY74CfD8fzqVXKxTRAnkzfsCcm4ypa5jZgsJc3tw8Fp0AAVYnhFUJL/ZahRTvw+Y86EbEnava/a6UPfl/Rb4zkfBd/jFTKyhcth8liqZdNeBumx+/ELC5L3lKAaBzm8ycIufUOFMvz/gsIvFBSS2ZhzqzSjk5hLP1uclalEpXKMFsbMuGMy7OWpUhAe7+DjWWvmnlXFLBuWAGr6M7dEcbtY7hlxkaMA7ekp3lrEAPa74r/thky7uZvvrE84jDadxzrWA7nIg6pXt5zl3d4oAZHfgZSvl10O6nKuVgTmV6qrfYpXbYonYjjJoBMfF83ZCftPrgVsQ0OxNaflHD4HpV6lRr7/mB3d5cRHZQo28+TW5Q1m4Or+FolaTCjT4qrt5RvSAlHKgD4+p6cJE1UBb9K8yR4zmRv0Er4iNcKxy04x0Vnpb0gseTCQH0iwr1AOpJtGgOFrDLZV9Pg877ggkA960uhsgFW+fd0RpVOFbooQJpeKuPNZFCV4E0MpDlSIdrc+ZpYfZxlpFUfxOXAoVBU7dRjLI48i6VgBQnzh3fU62nYon5l7cc+oiaKTqJnuYE+bD/zdsfepl1u5b0B3hRzyIKKqWkq6g9I/RwAl4iWcnQoRbVzwiZDt4hJxLANrQm26yBQ2OM+yUTGrHqCFlFwu61qCfC8WslOFU36aLAJgOAePp4mpqED5j8tMxN/ZJSkOp7thMSXKgcrPS7nj3GWtIn9Rip/wbGV3tPJUs+3AG/tI0zHcJoPGf0VqiQ2YT5sPsf/fF9AcJUe+j24CaYs1wmJE8oufHqQjZMYR7eDL/FUJ1N5HA2zx f7WJjUSD fLq7X/b5MqYY/2bEDTvJWgpn3+/qv+y99k6vYtLYRQXCJa6mMh5SrZJ7MUr8nXjx88nStoUPUo92BxFyYjU2IlnuDx3XmJAMWgH1FcrQvb8spAI8SrnoTtMWjDWv1aBnlBogeNL96wHd1YwrUxny058l9eBCUojOzSjybFwMi/aoN+Mf4sKtqs3kWLUkPk9zqkkGUxjxVLW09buvCjaM6mx+YK3QZgbwttDNyfwzuwMcU5RUoHgRf6nUmWna/1SndZrfmpYbOMwIu6S6rZwQZCB24s2eodSQGYLc0HROCRsEtwrE= 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 at 09:14:55AM -0400, Pasha Tatashin wrote: > On Wed, Jun 11, 2025 at 9:06 AM Pratyush Yadav wrote: > > > > On Tue, Jun 10 2025, Pasha Tatashin wrote: > > > > >> > > I think it should be the other way around, KHO should depend on > > >> > > !DEFERRED_STRUCT_PAGE_INIT. > > >> > > > >> > Agreed, and this is what I first tried, but that does not work, there > > >> > is some circular dependency breaking the build. If you feel > > >> > adventurous you can try that :-) > > >> > > >> Hmm, weird, worked for me :/ > > > > Worked for me as well. > > > > > > > > I am super confused, it did not work for me over weekend, and now it > > > is working. Even `make menuconfig` would not work. Anyways, I will put > > > it in the appropriate place. > > > > > >> > > >> > > > We will need to teah KHO to work with deferred struct page init. I > > >> > > > suspect, we could init preserved struct pages and then skip over them > > >> > > > during deferred init. > > >> > > > > >> > > 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 here! > > >> > > > >> > 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 early, > > >> 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. KHO already accesses stuct page early and uses page->private for order. Since preserved memory is reserved in memblock, deferred init of struct pages won't touch those pages, we just need to make sure they are properly initialized at some point. If we don't expect many kho_restore_folio() before page_alloc_init_late() we can use init_deferred_page() for early accesses. > Pasha > > > > > -- > > Regards, > > Pratyush Yadav -- Sincerely yours, Mike.