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 9AF97E77197 for ; Thu, 9 Jan 2025 14:32:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4AB46B0083; Thu, 9 Jan 2025 09:32:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DD4906B0085; Thu, 9 Jan 2025 09:32:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C73F66B008A; Thu, 9 Jan 2025 09:32:32 -0500 (EST) 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 9C1CA6B0083 for ; Thu, 9 Jan 2025 09:32:32 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B350DB146A for ; Thu, 9 Jan 2025 14:32:15 +0000 (UTC) X-FDA: 82988153430.01.D5A837F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id E64BAC0021 for ; Thu, 9 Jan 2025 14:32:13 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf10.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736433134; 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; bh=NWAhHox9z1pGuktzjGrZ9ZPbtvZRaueR8hk7/jquBck=; b=Gm0GbmYtes5GDWgAEflwRbdjJBA5w+hpBfr74YLKv5TwWE77yqaSciTVig+zTqKhl9RKwJ 1v4uWH6QVXgMwb/duJI61zYr859PjGXJPnVtUaVMar7nc6xRoml5/bT4FhFCk5gZ1QefzU 1DcsrKnkNblRHXW7V0mKLt4Dgc3wiU0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736433134; a=rsa-sha256; cv=none; b=rX/68e6lg/W0FMUz2SV7Qs+PYficHoZUmjb3epAXTB70BDeVJ9MctBQAtw63BTQJEZgyTj U7uahMcebNBZIkgJ5K2KtikRbhQpbBZIGpOXiLWAp/AnMcZ8xLfUw5M20CHmcc7AWwDDdV RsWy2I40Geeq8n666VyysQJWJksytNc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf10.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D1C6F5C5AE4; Thu, 9 Jan 2025 14:31:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7948C4CED2; Thu, 9 Jan 2025 14:32:09 +0000 (UTC) Date: Thu, 9 Jan 2025 14:32:07 +0000 From: Catalin Marinas To: Zhenhua Huang Cc: Anshuman Khandual , will@kernel.org, ardb@kernel.org, ryan.roberts@arm.com, mark.rutland@arm.com, joey.gouly@arm.com, dave.hansen@linux.intel.com, akpm@linux-foundation.org, chenfeiyang@loongson.cn, chenhuacai@kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, quic_tingweiz@quicinc.com, stable@vger.kernel.org Subject: Re: [PATCH v4] arm64: mm: Populate vmemmap/linear at the page level for hotplugged sections Message-ID: References: <20250107074252.1062127-1-quic_zhenhuah@quicinc.com> <406d5113-ff3d-4c2a-81f0-de791bcbeffb@quicinc.com> <1c1504a7-3515-48f2-8ca7-15b2379dea22@arm.com> <1515dae4-cb53-4645-8c72-d33b27ede7eb@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1515dae4-cb53-4645-8c72-d33b27ede7eb@quicinc.com> X-Rspamd-Queue-Id: E64BAC0021 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: y5mjp9j4omtaj1pif63k33ppjbdqtp7d X-HE-Tag: 1736433133-233928 X-HE-Meta: U2FsdGVkX18sOoIjC6Ki+lbb4xdk4/XCSD14AHSzmCkQUsZAsilsqKDa3zW+t9v+ZOIDHgbpI6IIdqtkdyKmmKvyu2HgepyINhfzt3xjpgyw2a3ML6luJIlmusXW9WXTgBjuTp3FF8fBw67cEbA+RwTQy8Hw/FF4uNkNm8Ep7JDUYKrZorbLvYnQ3KxmtO/y+2drYaezTq6xlRRYTBvpiqbc/uVcWM3AJtzcy8U0tHweuG56cx12cSFxlr3h8+Z9pntUggTALw3Y9iibjO3+9pEY0rVBJq80AANdfjRtUrzzgIa90vhbMdWChcFcmB0Qhs2PrnP+P/1nLOV7WI3oIG0xKcYUSCMr/h/wU1IyjUYQXu/B2zit6bT9n74Xkr0rspCYgFDxuiLHhcPkQP8aSA99MM7ycqULQfMU2wmwQW59BwmAk358bRfeh4SB1j76mRFFxEsbrRsqi45G1owxA5m+B737/iUwM05RXEe9n7AGhDE2hjDzemDS7wk1lD7Ez/zI5Hvxv7W9wIQiN1gCt1STitPGfe4Nq+kx9VPh1wogAdFWZ27Xt/ezSncuY9tjsDlEMc9v8m4GR/gm70g2lCEr4PV1WEri3MQxuW9SiprlTdB6gD8Y9DpBETJp7NHX0o0WIJUeUGusvT+TKtcIcVil4u6dJObIaHO/0mihkaq/0NRjO5rmp4I5vqdX3GoUL2HYFYak32WPoGEJbazvuxrHhMc+L5DphKha5KMN7GRgMmU/fzAY1ltlRaYzpKdjZsPfHwhi5LIjBYh3WcNvVrcpvD6r9nRckWHIXDl2thWye7hcf0jDDB+H3dfQJoRvT/ANhNpsA6BYa3YydHVsQA8grkXuk0VmAeZn+tX3mrj4BjG/tipP/lT0PtVIi/muAUlnett/qTTbNuyoDk/pVfY4R+3ffabi3AL3XDec1cfAANh4Y7ivsxUdm3x0kY6XlAbiqlmlBGpQbdtwRMC Gf81NEiR leBoBS0JSt5IMwOcTW4s4YqqH9Jvx0ZZFs9XnKN6sj1ywz7XWdGsADjDe0HiKMcN0PQfBqXPbuKY0Ae3Vw8ccV0GhqGy0bbjaKp79c1a7zT1gB3XbuZqYbqLeJPEwhd3PqC06/g5+Ip6M3DmrUu/4JkhS6y5yo3tlnXkKpApFO7qCZkXWwmzvhjhsmlF9EJ6e5SNhP4N4qFufi3f/GHVeT2lTPLM+mMiArmUAgy9QJo++u+237Y8yVafMZAq22twCtWImO2dQUPu/NVVgej3tLLlZkTIV71TiL210FtuGBcBSlxMYCVKiDn63zt3aQ0eVV802XXyYVogH4aGHzUqFtjQlyIFwMn73jiAJ0egZZEeLZB0evtveWMMfVSpAZJEdmW0oWeiIbx9GxUSYl80mRnoGDg== 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 Thu, Jan 09, 2025 at 03:04:22PM +0800, Zhenhua Huang wrote: > On 2025/1/8 18:52, Anshuman Khandual wrote: > > > I found another bug, that even for early section, when > > > vmemmap_populate is called, SECTION_IS_EARLY is not set. > > > Therefore, early_section() always return false. [...] > > > Since vmemmap_populate() occurs during section initialization, it > > > may be hard to say it is a bug.. However, should we instead using > > > SECTION_MARKED_PRESENT to check? I tested well in my setup. > > > > > > Hot plug flow: > > > 1. section_activate -> vmemmap_populate > > > 2. mark PRESENT > > > > > > In contrast, the early flow: > > > 1. memblocks_present -> mark PRESENT > > > 2. __populate_section_memmap -> vmemmap_populate > > > > But from a semantics perspective, should SECTION_MARKED_PRESENT be marked on a > > section before SECTION_IS_EARLY ? Is it really the expected behaviour here or > > that needs to be fixed first ? > > The tricky part is vmemmap_populate initializes mem_map, that happens during > mem_section initialization process. PRESENT or EARLY tag is in the same > process as well. There doesn't appear to be a compelling reason to enforce a > specific sequence.. The order in which a section is marked as present and vmemmap created does seem a bit arbitrary. At least the early code seems to rely on the for_each_present_section_nr() loop, so we'll always have this first but it's not some internal kernel API that guarantees this. > > Although SYSTEM_BOOTING state check might help but section flag seems to be the > > right thing to do here. > > Good idea, I prefer to vote for this alternative rather than PRESENT tag. As > I see we already took this stage to determine whether memmap pages are boot > pages or not in common mm code: > https://elixir.bootlin.com/linux/v6.13-rc3/source/mm/sparse-vmemmap.c#L465 The advantage of SYSTEM_BOOTING is that we don't need to rely on the section information at all, though we could add a WARN_ON_ONCE if the section is not present. -- Catalin