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 F338DC369AB for ; Mon, 21 Apr 2025 16:41:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E358F6B0005; Mon, 21 Apr 2025 12:41:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE5576B0007; Mon, 21 Apr 2025 12:41:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CACFB6B0008; Mon, 21 Apr 2025 12:41:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id ABBE76B0005 for ; Mon, 21 Apr 2025 12:41:51 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BCB168085E for ; Mon, 21 Apr 2025 16:41:51 +0000 (UTC) X-FDA: 83358617622.06.EB6402B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf15.hostedemail.com (Postfix) with ESMTP id 20215A0003 for ; Mon, 21 Apr 2025 16:41:49 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ppmL1iJM; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745253710; a=rsa-sha256; cv=none; b=XFmmSWaeHoHCPTV0VHaCwlW7GXUx1vnemBZ9SCszkK7IKYiqgDj1OR+Rr7dCD+xce7yi9W 0I+towo4Um+itOKPkjvUQZDTEfIX09W8PdUpGtrSp39DRVtR9YzS1LDZBc35Gm8DkNLT/i MjoVWSd91DA2knoW2vDPmF3tJlBncrI= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ppmL1iJM; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745253710; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=La23lfMLuAJ/7I6U9JVGJmkoB1vRtu5ZS9buyNYxVPY=; b=kQd7Orj4KrpGNaWjKF3Kyf32Au/GqmzD3Hn5sBS3B5kWKOAicXITXnLbfp4xq+optSxNYh bJY8j/1pZ2IDKMxVS4Y4FkAdSonB7ByTrA9gF5KdE5SMahCmfXHlSzkEPqTkIRX6YkxS1/ 09aBTkfnxeWesjxeToXt4FRzPeuM6Mg= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E6F0E5C49F4; Mon, 21 Apr 2025 16:39:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8FEFC4CEE4; Mon, 21 Apr 2025 16:41:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745253708; bh=jy6cMfB0NT9IYZb7KcMgcJtbrCslLbtDJ8MnDdG6GhU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ppmL1iJMifKsQCp2oO73/Ce4Sw6SZZD2MdiNYPDPw6PNIDc3qzLJGr/FuPeBPpTwV hs2imL0rqpc2kGQN2C+GDwnVTrPfwiWudtnFuaM/+wqypSiL7PLP/VbHx9XPKE76eK Myh1OfhSU1CuS4LwApRfacpDNl2HOdVO6NKx0omyjYJU+mxkNxxD/CndkhdQ6rRfhX padtlRM/AP/fq5LH/j6A383Kb1asRqdftQmn5zMr6HzCm++ztdOrCCvKyeeWNFMCLJ vQ2Ka5Jr855tAX3zaRsNsOjzsCoDbW70tiP5frCNQML5cuf8W9m2UWw7zKDFRgHXIt B0Cr/xpY5gHoQ== Date: Mon, 21 Apr 2025 19:41:43 +0300 From: Mike Rapoport To: Ruihan Li Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/mm_init: Don't iterate pages below ARCH_PFN_OFFSET Message-ID: References: <20250419122801.1752234-1-lrh2000@pku.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250419122801.1752234-1-lrh2000@pku.edu.cn> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 20215A0003 X-Stat-Signature: j9qmetyf66qur8ghor8eao1kp65f3sc7 X-Rspam-User: X-HE-Tag: 1745253709-639755 X-HE-Meta: U2FsdGVkX1+/PypGPlX2DPQxf4EzXJy2oW+aDi6bFFfXFvNuC8Q2ovUVRIMg2tsBkrlGarGAwXh8qfFjc2K5jUsnytIcw6eRFIDsbG1qbkTmuecqx7ukHbKm/cC/7BdFn3yOCU+/A49nN0OoLqEvOg+XRtBQ7TFdgg14cpf9zGPJIylo7AjCjHkEKqwgKubSX1QFkDo1IcMqHK1IieN6c7NMV7FlWISTC3hi45+HQ8xVh+lySblztVZszSR6gcoEoQzmRv7J/sQgfA6ZLxRONyLpiIzgOzE+jQG578VSvEcyopIxovi2/QW88y0CIXXqsZWP6pTHE7hXv3R8Gh3tTIgx9ObrNzJdmGIpD1qQzil8oU5dKMMY2P2jlMIezWCm9nxDuAwMRSobybALo8uzSgV67qAg68Q5KTbm9FjP8SRl7f41lzNRmYS/ZQPx3Dpse1ofLO6qucnCSYUupLQEnl+Y2rrcBjnp05PodTsLQPyc3y49AdBCIgHewf4sw8pLHrn0TBtKhtV1S7drfwMXvXCCmDIHnG6ZW5EcNqcNDy0AKP+tAcHNZ/Xh4WWIREz1hzm1yCwVlmgBQytph8fEj8rpOB2Cp6OfwmiZQtM2EqTqA40LpgL0InR+LfcbXZbb+OfRd6GMhlpjVeGot2rYpsGgtUx/trs4RgIgP1E70H1rN5hjx0U9Nuvl0kmi4k5mubyxXLmgPp1X+bm95fa2BLRDXW2pWa6v8De1Bb+H+Z8DwNXTd+akvJ4Mow9/t31mZHoF0Kc0LYLONYwf9QaU8fDwQj0qqFxOd+bGKOktFk4MxaWM/F0P4PJScWPcr10UyHHphcNGb6nyxA+g2zEP3DL+C3RhVBJekff/eS7jKbMi1ykyUaNRxlmMUGY692e4VpWciOMCdfrascAz1fj1CjRumrjkTAFPndjmrXDsVtkuecuQ3c23y8YGMWSkyyB5z0/gqEm9F7clTJlzM5+ OZZkCDTR 5dplHVhPiKt+Xvghkk8sHo1BYquw79HL4kdr1DR/PDY6AjfdTd7Lr+P7mdmKwm+4hMPSO7OeJtlBq2Uj3W77e8jqBPcY9ykwU9AJnkPTaOv7s098yJX4E9iW/tED3MscbDwt3XvLMoUPLQrhh6tIlb2mx9FbLoz6/rji+asM7p+h+j1FxjSwNZ1EkTR8JHdZZ5uhcQEe51qzBcKIQtyD+3ug3tXpj7n7jt9lIqloIooVa8pL1bjrAPw3Oj286Twh7ndpBGreRGoXHDh/TLlF+ztiKIBeVcB1UNCr+PBT3I2u22OOfvoxxlO7yRCu1hqp7XDY0kBUk77CYnwdbMfogGY+AtRIdC8x3Kp+zbuRbMZJyszNb7jBJCZ8ewiF3Qw6zaxwS 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 Sat, Apr 19, 2025 at 08:28:01PM +0800, Ruihan Li wrote: > Currently, memmap_init initializes pfn_hole with 0 instead of > ARCH_PFN_OFFSET. Then init_unavailable_range will start iterating each > page from the page at address zero to the first available page, but it > won't do anything for pages below ARCH_PFN_OFFSET because pfn_valid > won't pass. > > If ARCH_PFN_OFFSET is very large (e.g., something like 2^64-2GiB if the > kernel is used as a library and loaded at a very high address), the > pointless iteration for pages below ARCH_PFN_OFFSET will take a very > long time, and the kernel will look stuck at boot time. > > This commit sets the initial value of pfn_hole to ARCH_PFN_OFFSET, which > avoids the problematic and useless iteration mentioned above. > > This problem has existed since commit 907ec5fca3dc ("mm: zero remaining > unavailable struct pages"). > > Signed-off-by: Ruihan Li > --- > Link to v1: > - https://lore.kernel.org/linux-mm/20250418162727.1535335-1-lrh2000@pku.edu.cn/ > Changes since v1: > - Removed the unnecessary Fixes tag. > - Fixed the build issue for CONFIG_SPARSEMEM. > > mm/mm_init.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/mm/mm_init.c b/mm/mm_init.c > index 84f14fa12..a697a83ff 100644 > --- a/mm/mm_init.c > +++ b/mm/mm_init.c > @@ -969,6 +969,15 @@ static void __init memmap_init(void) > unsigned long hole_pfn = 0; > int i, j, zone_id = 0, nid; > > +#ifdef CONFIG_FLATMEM > + /* > + * Pages below ARCH_PFN_OFFSET are invalid as far as pfn_valid is > + * concerned, so don't waste time iterating on them when looking > + * for holes. > + */ > + hole_pfn = ARCH_PFN_OFFSET; > +#endif > + I'd prefer a solution for both FLATMEM and SPARSMEM. David Woodhouse proposed a for_each_valid_pfn() a while ago: https://lore.kernel.org/all/20250404155959.3442111-1-dwmw2@infradead.org It can be used in init_unavailable_range() and will essentially skip the unpopulated memory map. > for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, &nid) { > struct pglist_data *node = NODE_DATA(nid); > > -- > 2.49.0 > -- Sincerely yours, Mike.