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 8B3FEE7719A for ; Fri, 10 Jan 2025 03:13:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F0C3B6B0093; Thu, 9 Jan 2025 22:13:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E94086B0095; Thu, 9 Jan 2025 22:13:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D0D936B0099; Thu, 9 Jan 2025 22:13:42 -0500 (EST) 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 6B71A6B0093 for ; Thu, 9 Jan 2025 22:13:42 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1E39C1C6A87 for ; Fri, 10 Jan 2025 03:13:42 +0000 (UTC) X-FDA: 82990072284.24.F0FA757 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by imf20.hostedemail.com (Postfix) with ESMTP id BAC751C0012 for ; Fri, 10 Jan 2025 03:13:39 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=llvQAqGW; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf20.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.168.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736478820; a=rsa-sha256; cv=none; b=St4xv6mpdtt1+upqlYd7bmja68TknZtrRYMPiqBz+3Yu+LAwdPaxlTwPVtkDi9D4moLOiu 7wTeqli9xp3g4jvO0B+ZCcvCyz1JP66SEr2N/ZZDdvxXuCRQDv8nZTOwNSyd2Nk8brLpos qt7GJADT0gtMAoT65+xhwmSarbcRlM0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=llvQAqGW; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf20.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.168.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736478820; 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=fq7/wpTIKQ6rlSsWJvkOiFN+/C7V222Fj1m252h7CnU=; b=6tn+YJ+UjglZVYNKK2/0ci928KmoVoLimgyMiLBFNCXrlINhIAjbipH5KJE8PN7y+97MMs rmvJuhnXjpW0sBixeztjs/yvRLm8vO8i21p4omDnYkDuKdDjDkFCAtzbrHt8CAa4ZNW9rX 1tY8NkOYL0dntAx1hHLpdnZ+R8aAs8I= Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50A0XX24028314; Fri, 10 Jan 2025 03:13:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= fq7/wpTIKQ6rlSsWJvkOiFN+/C7V222Fj1m252h7CnU=; b=llvQAqGWITf76f2H 9nrzWubDDE3tK0YKtSXoRzf4BBqed90mor9A+DSs+ZwOg+MZbldBxT87WvBuEwLW uwES6ADlc8R5MJGrbSf2abprAYxSW6a62W66UkzKVYLx6T53ncv5nF86FaNjJaUV yOHVYO45cR/ND03l9Vj8DMfxG399YqUFKfHXt/uTTNAJmUoqlKe3n90ppg51ldOL 1n0noEHu2pOwym/0JRKyQQZwhdel+qvkmKueCxa4aZMNAZveJAusMwLKXJAFld4Y uS0njvetv0hMI3CcANzMUAiA3L1okcSngH0catIEi7Y8QrJ2MBUsVjR2C2l8En8k erYUzA== Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 442s4509vq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2025 03:13:33 +0000 (GMT) Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA01.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTPS id 50A3DWd5001263 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2025 03:13:32 GMT Received: from [10.239.132.245] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.9; Thu, 9 Jan 2025 19:13:29 -0800 Message-ID: Date: Fri, 10 Jan 2025 11:13:27 +0800 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: Catalin Marinas CC: Anshuman Khandual , , , , , , , , , , , , , , 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> Content-Language: en-US From: Zhenhua Huang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: jr38wu0jPi1WyjFwWcsWSY7Xw3cGEs3- X-Proofpoint-GUID: jr38wu0jPi1WyjFwWcsWSY7Xw3cGEs3- X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.60.29 definitions=2024-09-06_09,2024-09-06_01,2024-09-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 mlxlogscore=972 bulkscore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 clxscore=1015 suspectscore=0 mlxscore=0 impostorscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2411120000 definitions=main-2501100024 X-Stat-Signature: mrf3be6tro5kihzmghj4tsg6i3qsigp6 X-Rspam-User: X-Rspamd-Queue-Id: BAC751C0012 X-Rspamd-Server: rspam08 X-HE-Tag: 1736478819-454111 X-HE-Meta: U2FsdGVkX1/cG0IsaPZRtLif/nUNs0ukj83XqTZN7VN+q08o5Q6ZE0EnuUGLk7CJCXXT2FshAesfO7DYWPY+yt5Wh6LZcEqr9yZ6xXWBaw/cTSxuQo2aEGsZuS+o5QRLZyxYji8yVVe/9R7l5KB6S0eS3JEttbgRDhQEwhws/m/xgyHiINGBaKmSMKUfx+hHgx1pBKGwcgj1JFWwPfF1Kip5/DP8DFpWWb1tpavi+vjTYYe0Y+eCg0k/W3dtSa3f5zG6hw6UQfyYuA/pvmF09q5qW/5KvlyAaB+supX/zEdBoTET8f/iqjv0bzHqxWr3hnt4sS7QjExp02V4S2Lhqp34viXlND3cgBVbytDXPhsGgK1sZw/LDV6NN9uOvFtjgXuzCdqS/gCl81vNf+Z4PJNBGrtvyPY24FN6DhLoz6dc0A5o/WR3kmxg5avAae7hztKVidBIhPPQmAeyQlRs0PCmgEJb/WzdNg2oTIUIfTwsO9aYYsTQ1grd9M3MEOQ6N0qfUc1LxkofWICSrGA+SpgLnRf26JuzNTQ+SXk2t/xeTOUbDCC7l4ThPuWURH3f+S7dHtUjqIOkGJ0dTbFqxnk/ts2/KCaWAO8R2udAeUPMgkYpWIM0uAWoRDA/q04Suv9X6ocagdGc2NcM2cp/x7z87U9Fjbjrk4mZE5FZ+v7+LKmWwoFZY5F0g09Yr/vq90LNQ81HrJ14Gem9VR7qdfi0/3Jj9pA3es/AlGDX966/nUg9VEqIRfZaBZFduSV8QpO5EnB1a8Qx02T+1aDXGF9a+oAcBBM7UWvAxDseuiGoZEu0pVas5CLqql/1+wLNmWnrnxAwDKadfhebFapz1NSpKl5iz3sJqZ9gxw5wD362/66YlrxJYGiPUOhcJiTlFcMpDMnY5Dq3wQP10+ZUjqDYl3nryRfSxx6jyvTtGNaL4vVx7VJmdwV5BjUngS9W1jWDrp4HTX8gahDA5Ii C5sJSPST oOqmTpJOii2qbu4ryuugqSkr/IxmP3WYjuddpF6OUUUwTd6jqnL826eAcCovSCylBhiEEE1RoUtebPbgaHg2+gm/YgZHQzg3dtmTmND+Oc60jlbkekOY+3x4Oauk/FFMiBNO0fZnsYhjO1IxAWKu/bUYIUCaAt8BddQYPklaUWLxuV+9sjIVXJni1Qt8t8OXczfNJ4l0e45H9FvSZyWYciQM+RlghhnlLI2OQkEcDuQcw2LyIBkSACBI9uYgh7IFr+c010JLvBb/IWK2Ipsr8x7ikHI+DAQLHjv2FHwlUDhrTkwNKZ+CSTCGINptVYG1uitu9AVqPidKV6j+tyabAJA4Ip5bKOe0xfAYhN0cseRuptGF+NUrh4YlgyP5SnK6+nnnqdpCxstl+sti/Q9V6G9xtNfhMyLY7gYAXRG2ZiBPRDwCJTyu7I6d59b+J2moD/YDx 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 2025/1/9 22:32, Catalin Marinas wrote: > 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. Hi Catalin, Sorry, but I don't fully understand your comment here, IIUC we shouldn't add WARN_ON_ONCE in vmemmap_populate(). As you mentioned above, early code relies on section present. while the hotplug code does not guarantee, it will set PRESENT after calling vmemmap_populate(). By the way, seems you're not opposed to using SYSTEM_BOOTING ? If so, please take a look at latest post: https://lore.kernel.org/linux-mm/20250109093824.452925-1-quic_zhenhuah@quicinc.com/ Thanks very much! >