From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1ECEB1F75A6 for ; Sat, 20 Dec 2025 02:27:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766197655; cv=none; b=JqcJfe9lszhYlSA7OrtHVbBPWhTulR4D6R7PV0tIBnZGJmqoHqMapgjSv/fOg5WO6v4/oZzjJ0ZfnGEBz86o7pLBC6t0ETiH7wuahiHrrGYjMnEaFKj+fZKTy39nv1sP/Xz34zvX0uOiMZ+ZY5BZbGGbKGW+MOJI1DOsaKFlAJ8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766197655; c=relaxed/simple; bh=8gJbQgrMoqDVTMXtu843sIWuj5pklhAvmPm/aifE1ko=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=VMn8dLz9DBNEwzBx2ERCiKLn22XKvcUZQWEMs8ojY8g7Whjgb9A11cu6hxwTSaPUzerlQ6U1KmyV5hS1OtfamcXUl6oBv5SUKN1GEqYQNrD+oQ372LU7w0i9NCnuXaiZFhVQVVqEHc2rEiNhN8AITbwWujwU1SLNy+thVswDcMQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=chNtVVpz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="chNtVVpz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A908FC4CEF1; Sat, 20 Dec 2025 02:27:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766197654; bh=8gJbQgrMoqDVTMXtu843sIWuj5pklhAvmPm/aifE1ko=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=chNtVVpzYpRYAj8/vIOo8wxb6sD4anNSHoDTf3VFoTfx2iuUoEfN7p/hOZ70kpLPJ 2tqiaWsvEBz4295hBXG+7i7rkrPyjhKHbz2aoWLFko7yBXGtgrri8NkQM/fyJXTwp+ aboma+arqiJoas03/CAS9S1b6A+yu1PBBOeW4xu6AWnYMpA4W1fvXyRA6DNEpORmFK q9ZQVsgiqG4R1QYGIA8TIS23Izw7o1BmPziPcazKjwEmSK3M+VdEVhGDCrGFu30NNI Np07K9faJCdOIwFse2aXsfKpmAGY/tXErS0HIazzb6FCMlJG7zCz4QgkvJlq56DD7J woqh8h76j4HyQ== From: Pratyush Yadav To: Pasha Tatashin Cc: Mike Rapoport , Evangelos Petrongonas , Pratyush Yadav , Alexander Graf , Andrew Morton , Jason Miu , linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-mm@kvack.org, nh-open-source@amazon.com Subject: Re: [PATCH] kho: add support for deferred struct page init In-Reply-To: (Pasha Tatashin's message of "Tue, 16 Dec 2025 10:51:57 -0500") References: <20251216084913.86342-1-epetron@amazon.de> Date: Sat, 20 Dec 2025 11:27:29 +0900 Message-ID: <865xa1khv2.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 16 2025, Pasha Tatashin wrote: > On Tue, Dec 16, 2025 at 10:36=E2=80=AFAM Pasha Tatashin > wrote: >> >> On Tue, Dec 16, 2025 at 10:19=E2=80=AFAM Mike Rapoport = wrote: >> > >> > On Tue, Dec 16, 2025 at 10:05:27AM -0500, Pasha Tatashin wrote: >> > > > > +static struct page *__init kho_get_preserved_page(phys_addr_t p= hys, >> > > > > + unsigned int ord= er) >> > > > > +{ >> > > > > + unsigned long pfn =3D PHYS_PFN(phys); >> > > > > + int nid =3D early_pfn_to_nid(pfn); >> > > > > + >> > > > > + for (int i =3D 0; i < (1 << order); i++) >> > > > > + init_deferred_page(pfn + i, nid); >> > > > >> > > > This will skip pages below node->first_deferred_pfn, we need to use >> > > > __init_page_from_nid() here. >> > > >> > > Mike, but those struct pages should be initialized early anyway. If >> > > they are not yet initialized we have a problem, as they are going to >> > > be re-initialized later. >> > >> > Can say I understand your point. Which pages should be initialized ear= lt? >> >> All pages below node->first_deferred_pfn. >> >> > And which pages will be reinitialized? >> >> kho_memory_init() is called after free_area_init() (which calls >> memmap_init_range to initialize low memory struct pages). So, if we >> use __init_page_from_nid() as suggested, we would be blindly running >> __init_single_page() again on those low-memory pages that >> memmap_init_range() already set up. This would cause double >> initialization and corruptions due to losing the order information. >> >> > > > > + >> > > > > + return pfn_to_page(pfn); >> > > > > +} >> > > > > + >> > > > > static void __init deserialize_bitmap(unsigned int order, >> > > > > struct khoser_mem_bitmap_ptr= *elm) >> > > > > { >> > > > > @@ -449,7 +466,7 @@ static void __init deserialize_bitmap(unsign= ed int order, >> > > > > int sz =3D 1 << (order + PAGE_SHIFT); >> > > > > phys_addr_t phys =3D >> > > > > elm->phys_start + (bit << (order + PAGE_SH= IFT)); >> > > > > - struct page *page =3D phys_to_page(phys); >> > > > > + struct page *page =3D kho_get_preserved_page(phys,= order); >> > > > >> > > > I think it's better to initialize deferred struct pages later in >> > > > kho_restore_page. deserialize_bitmap() runs before SMP and it alre= ady does >> > > >> > > The KHO memory should still be accessible early in boot, right? >> > >> > The memory is accessible. And we anyway should not use struct page for >> > preserved memory before kho_restore_{folio,pages}. >> >> This makes sense, what happens if someone calls kho_restore_folio() >> before deferred pages are initialized? > > I looked at your repo. I think what you're proposing makes sense, and > indeed it will provide a performance boost if some of the folios are > restored in parallel. Just kho_init_deferred_pages() should be using > init_deferred_page() to avoid re-initializing the lower memory pages. > Also, I am still wondering how it will work with HVO, but I need to > take a look at Pratyuh's series for that. The HVO optimization happens when the file is retrieved, after all the folios are restored. So that is long after deferred page init. For my series both approaches should work. --=20 Regards, Pratyush Yadav