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 ECECEE77188 for ; Wed, 8 Jan 2025 10:52:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E3766B0099; Wed, 8 Jan 2025 05:52:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 692DC6B009A; Wed, 8 Jan 2025 05:52:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5817B6B009B; Wed, 8 Jan 2025 05:52:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3A8C86B0099 for ; Wed, 8 Jan 2025 05:52:37 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C0E59121144 for ; Wed, 8 Jan 2025 10:52:36 +0000 (UTC) X-FDA: 82983971112.17.305FD87 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf05.hostedemail.com (Postfix) with ESMTP id D2FF610000C for ; Wed, 8 Jan 2025 10:52:22 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736333543; a=rsa-sha256; cv=none; b=c0OzQlHv7Ts8q7VLf0BRxE1KkMopuq3B31rTl4NvmljPP/5OHZLdq9QjBD1NEkBO0LIw8E Z7eVb5LGBQQOhMp3Zzkc7FEUlW+B0pGIrE8dHZxJIjenvcV0xZdqsPiiQ1wPjpPf4utw3V A4nflDkqjm6T08CdNpwiFigCKp8eYoI= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736333543; 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; bh=j4wmS7H8dGfpoIByQwrpWO7x+faK8pib1ddK+J2PaS8=; b=ngQ4m5NIwhVWwAJe2IARdU6CtJ4uKqRMXgFEwWMwT+fGsQ0xzc7F9Mzy4TojtvRMqR9UU4 gonKaB+YkzndSuOy4BNpx7Jr+u/ueRM4zYMkOz3b3wpbJKJWD4QS/aJCBmeTBik0t/nLj8 p35mDUzqf3IDL7clBqnI2U5Eiv3p6+c= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3275013D5; Wed, 8 Jan 2025 02:52:50 -0800 (PST) Received: from [10.162.16.95] (a077893.blr.arm.com [10.162.16.95]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E67693F66E; Wed, 8 Jan 2025 02:52:17 -0800 (PST) Message-ID: <1c1504a7-3515-48f2-8ca7-15b2379dea22@arm.com> Date: Wed, 8 Jan 2025 16:22:15 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] arm64: mm: Populate vmemmap/linear at the page level for hotplugged sections To: Zhenhua Huang , Catalin Marinas Cc: 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 References: <20250107074252.1062127-1-quic_zhenhuah@quicinc.com> <406d5113-ff3d-4c2a-81f0-de791bcbeffb@quicinc.com> Content-Language: en-US From: Anshuman Khandual In-Reply-To: <406d5113-ff3d-4c2a-81f0-de791bcbeffb@quicinc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: D2FF610000C X-Stat-Signature: b6iy5ugfgj7o5m5icc7qkb9jj3sy3bfr X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1736333542-180718 X-HE-Meta: U2FsdGVkX19mxDM9xRfx+ldRqX5UmVURqySQAp3oZDNq1WLqWYtIAg79Z/bHT90/x4TrSV7w27Wr3SPz++XNP/H7NIYpMxB+ouy9owIF7xuzeHZidqM0Q7Fv3bkOI0PUrHAvar/36R53UtY9JpQiiUphvw6P3ZURDlpgOJnLV/baKQJyOapU/rk7qsuRAHgmnka2kTyYr6e28mBnuuTusOPWQZAXoOyU0Jg2dEH835tCPrvGCw1HfoPJC4YIlljkrI1XaE+R4YMbF4OSKmhaKdHAfgDzJvFEHdjm/MQ8jSpgXzMr2/3UupCxAKW6FkR/wb4U82Ig24FmlWeTqzDxBoucMJiCYltkGg1CExqa/UWD4w9fmpMVToAN6Uj4MXP6z8yQ9s4fDJsK4wECGwcuJisBvHo+ZJ4OqgEytcKe5rEovPnlqb/9YN4VCqzHrO6sO7qE0aq4j7RK3D2E3NC+bVa9iBATtZNk8Vn3+rFdgJi+3vKLCDmvNTt/dGhhvJmcFxOxBR9cvhFfsOcVMlxvZQiHLE0Oh9Y90SyKro9Yqyo2l7uWqP4TGVBCMeBzQKZ9lx6yqIK/2Y2y68OUN7qnRJOxMWDMXkrcPrctVxboln+GA1KNI/PgjfiyYIeQr/Ss+v3tigRNfJSAJxKZqN+bmDzaJ8DFOjQAoFAoyW9U/34Ra1NckOMSAp8G2cT1vMFexlKZN/Wt6JfAdTrZqWgjdA/ePshCI9zuj1Vz8oV8Y5xNNoKgvOVb5Nrjl5QywXjKdpkx0OYUNRikx84iGXeEzmPgu1vneDvyqQHEbeHLqoyInOJOgv+zWk9rkj/mFla+PU/B1q701W7QGZEqjyUF0vOmdhM5cBU8ORaF0Aj8uMunE9q8dqqQrNy9fs6TzZZcAr9nWy+HlIVHiqgiNBELYIdRT/1cIDZQOjgcvil7Rsup0cybJkKGebAeyAcy2n8k3A5FDNXnLTDYveafMuP 9zHkdenb ILmMYiU1hDipKpbDe0jJqJuDRS2NyTiZsVy1GU90UMCiRNUukLjCo2t03gzALWRxqt06XjIdWvI4tU6vuK+NF0UwRX16od7FunNv+0B8zg3YBCK0ADDXNDLvmB38JJ2mMEdYi83yA6dmF+vIF1fubNAJgK4syzEYzb7zkiJFqVxSt7lo= 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 1/8/25 15:37, Zhenhua Huang wrote: > >> >>>                 /* >>> @@ -1175,9 +1178,21 @@ int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node, >>>   int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, >>>           struct vmem_altmap *altmap) >>>   { >>> +    unsigned long start_pfn; >>> +    struct mem_section *ms; >>> + >>>       WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END)); >>>   -    if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES)) >>> +    start_pfn = page_to_pfn((struct page *)start); >>> +    ms = __pfn_to_section(start_pfn); >> >> Hmm, it would have been better if the core code provided the start pfn >> as it does for vmemmap_populate_compound_pages() but I'm fine with >> deducting it from 'start'. > > 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. Hmm, well that's unexpected. > > 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 ? Although SYSTEM_BOOTING state check might help but section flag seems to be the right thing to do here.