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 1823BC282C5 for ; Mon, 3 Mar 2025 09:30:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A172D280008; Mon, 3 Mar 2025 04:30:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C5E1280005; Mon, 3 Mar 2025 04:30:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83FA7280008; Mon, 3 Mar 2025 04:30:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 655E6280005 for ; Mon, 3 Mar 2025 04:30:19 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 17028C0563 for ; Mon, 3 Mar 2025 09:30:19 +0000 (UTC) X-FDA: 83179718958.23.D49FC6C Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf19.hostedemail.com (Postfix) with ESMTP id B0E171A000F for ; Mon, 3 Mar 2025 09:30:16 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=ApAYQhp+; spf=pass (imf19.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740994216; 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=r2jFIZdUKx5Dbc3ZCsERsiLP2tPI95deItMdu/Cb6SQ=; b=0z9HTZhGky+GD7zIXD5NsSQ+HrSDJ4SjSq+5QZJJiS+TXtDMtiV0TMnqlCBrqAqStjurZy fZoTwzRvY9KeiSHSNfA4PNmOIDGzVWOSi0wvxFLo/pfa1l1HlMxVs3kuFFA9j+SfTE4e/6 cqCYku+qORbC3lismgnaDRW88QxzM5Y= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=ApAYQhp+; spf=pass (imf19.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740994216; a=rsa-sha256; cv=none; b=CirPWvuPCOwrTSkqUPAbxPQE1nYQytUkXXQjzH4cT3W6GK6Z/eBoKaLOn7q1cyfRV/Mhp0 ndxJh1AZqwc2vdV1bSJimthKB5fysq4mMlHOIx8nujQHYlISQAkrMh+Hm82rdpiXTotvv3 48P78NBqKlE2u9GbLgqHFQvLornjG1w= Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 52309L9i002169; Mon, 3 Mar 2025 09:30:10 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= r2jFIZdUKx5Dbc3ZCsERsiLP2tPI95deItMdu/Cb6SQ=; b=ApAYQhp+bBNOfR+2 vDkaPsNp4jGa2/W771Qf0oy2K2APdg/A5NF9z0uEhHzd9O0xqpmJsWCB0/OIrd6Y xLBzECAmWMGyMTbHNtoUhaFQS5ZgFFkuLcWU4TAcZu0hKpHsBwo9nEaMbg87C9hz 6haYxN3PRFBzSEcAR4jI8RBMCLEY9Ke/NjIKJ1O1f+7V9VhpOG2AXmiDVC2xWuhs gETA/5iZf7WOcTf5sWes14WNx5Rpaxuch+FFte/i3Xn31MeX4HtJvLBrUnIsHttR l4FstB60v1frcIm2QzUpcZkcSi4BZvQgxsX7Far31EQqxD3j+86u6Ui5sGYoPOHR obSqcQ== Received: from nalasppmta02.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 453t88vf7v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Mar 2025 09:30:10 +0000 (GMT) Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA02.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTPS id 5239U9Gp017890 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Mar 2025 09:30:09 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; Mon, 3 Mar 2025 01:30:03 -0800 Message-ID: <45076e28-dd70-456f-83b2-7b4d532c455c@quicinc.com> Date: Mon, 3 Mar 2025 17:29:55 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7] arm64: mm: Populate vmemmap at the page level if not section aligned To: David Hildenbrand , , CC: , , , , , , , , , , , , References: <20250217092907.3474806-1-quic_zhenhuah@quicinc.com> <8c1578ed-cfef-4fba-a334-ebf5eac26d60@redhat.com> <871c0dae-c419-4ac2-9472-6901aab90dcf@redhat.com> <00c82c92-35a0-441c-b5b5-e4a6c8a4a9b7@redhat.com> Content-Language: en-US From: Zhenhua Huang In-Reply-To: <00c82c92-35a0-441c-b5b5-e4a6c8a4a9b7@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) 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: jBcZU8ak7qkip-7X9ZyIEw8nwf0ChjlD X-Proofpoint-GUID: jBcZU8ak7qkip-7X9ZyIEw8nwf0ChjlD X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-03-03_03,2025-03-03_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 suspectscore=0 impostorscore=0 spamscore=0 phishscore=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=999 mlxscore=0 clxscore=1015 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2502100000 definitions=main-2503030072 X-Rspam-User: X-Stat-Signature: o1f6sxdixoqox9edhapb57ui6a4cwhm5 X-Rspamd-Queue-Id: B0E171A000F X-Rspamd-Server: rspam07 X-HE-Tag: 1740994216-141960 X-HE-Meta: U2FsdGVkX19NiIUEzT9zTKn1fi4rAMuZ4oF1srBav4xM5FQ9dSKWsG5WNMVqOFhZK1Ey9COiClz420XpMO0BS+AJG8Mnh8d+O4JVJg6nDpzMrMJIM/B5CZ2aaXUNWIwqH+G8fj4ZrpqaTDFh+QSZfI5q+YRDnhUP7ewHl3WujX9+MPjpzi2HOLISdo5UUl3l3Z/pHCQW5ceMaTNSZqGNjRBmEyK2M5IsZrs2HCUo+ykhGzNRKwzBc0GH/mYPUGxlrC+91gdNvYF/NEROsnbWBTIggY3uaE5g9nq76H4lCBme6l87IEtxYWv/SRB0DHLM3tP5fMIZQbTWdfk1yVZznUtXhuoI3tXbjWOGlO/XDutQ6N7T2MjBWy3BUpzkvfZuHNye2wsCFaCZA5RP6AQYxJmnm1380SNb9C6gytztt/a79k201a4kcd0gAjvnxfbuSMGmXaF2yiKjhxHpFZUIBdmdZZh/lYMLWUkEAwtjIElJ7Y/dui4pbbbBbC9rC8SW8Zlw6+JIelh+Qw8SW3B1jEZxbU0/k3Fyvk0AkrYmMwzn5mB2iiyPSYtT8++QHStZ7MG9iv2Be0XzPPL4ybaw2qfx8wcngYJBibPjvgYnPPd2mlFORSaziTLvrY8em7Q4k3zDqq4DQVLNmPgDDh/d6LzDrjTqeCwWbEXE8NnK3yO1A833N8NJcaRGyOd3nMICshSi5mVZOv3dJ6IX8lUMIqRP8ZAGZqhdVhOH+bLpImh8a1tHheh9a+1J9uZklipst/5BXWkHQDYt4+Nvn17xffI4trMGT36ikD1FxCwcjZjukgDmPDxOpVySoOzs+AoAQYaq0OV9eSL8InqR35aiUkbY7262RDvqKHDvxSiVOpHRfVsmzIBzWXGnGjIK5AHh1jhz00Ure1KBA7kjpSydSm5gorZnx0B1NjpttEPkww1u9OhkGw1NrWJf7Y6iunjKvNWa8/N/wW/v9QrjViv GTBcBSCH W92KxklO9wkPmLHlpMJy0wBCs/fwuh3RIGAx2P+RWfTFTtQeK6ndAPDGlJYk8FVpSRyIMiUKDrtFCX5q1rzO9mgrMmkZ/CJ3ru2/5Lcq56QHol9FdVK3gXKML+XaoZ7Irb/efLfsx33+GGsv6DP8rfcL7FtML03ymOBEGYDx9L1ZUX1rL54N5JS/xy+SlisrEdTBmNk5pUJSAgFdKqtUHQ7U5KTrkDjyIrZuG6zO5gBNaOP5BGaz00GfhckZnGF0R72ICcKeLF9ZTL58c06yq6GUTkoMNtM9X/Ne4lDOIpe8hwXrXQjb9DtmxUCOspIrPAI8uErL8ohNztpzc4+EFn7zgieHL2j6xA3Yx21AcqKq/o9f7iC9QuPR7CmjZwPPS9Ju5hql/EHcdgqsObXGsZVrtA7DX7TtxRZsS 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/2/27 1:13, David Hildenbrand wrote: > Sorry, I somehow missed this mail. > No problem. Thanks for your reply. >>>> Hi David, >>>> >>>> I had the same doubt initially. >>>> After going through the codes, I noticed for vmemmap_populate(), the >>>> arguments "start" and "end" passed down should already be within one >>>> section. >>>> early path: >>>> for_each_present_section_nr >>>>      __populate_section_memmap >>>>          .. >>>>          vmemmap_populate() >>>> >>>> hotplug path: >>>> __add_pages >>>>      section_activate >>>>          vmemmap_populate() >>>> >>>> Therefore.. focusing only on the size seems OK to me, and fall back >>>> solution below appears unnecessary? >>> >>> Ah, in that case it is fine. Might make sense to document/enforce that >>> somehow for the time being ... >> >> Shall I document and WARN_ON if the size exceeds? like: >> WARN_ON(end - start > PAGES_PER_SECTION * sizeof(struct page)) > > Probably WARN_ON_ONCE() along with a comment that we should never exceed > a single memory section. Got it. > >> >> Since vmemmap_populate() is implemented per architecture, the change >> should apply for other architectures as well. However I have no setup to >> test it on... >> Therefore, May I implement it only for arm64 now ? > > Would work for me; better than no warning. I made one patch several days ago, could you please help review once? https://lore.kernel.org/linux-mm/20250219084001.1272445-1-quic_zhenhuah@quicinc.com/T/ Is there anything else you would suggest besides preferring WARN_ON_ONCE() ? > >> Additionally, from previous discussion, the change is worth >> backporting(apologies for missing to CC stable kernel in this version). >> Keeping it for arm64 should simplify for backporting. WDYT? > > Jup. Of course, we could add a generic warning in a separate patch. > >> >>> >>> >>>>> +/* >>>>> + * Try to populate PMDs, but fallback to populating base pages when >>>>> ranges >>>>> + * would only partially cover a PMD. >>>>> + */ >>>>>     int __meminit vmemmap_populate_hugepages(unsigned long start, >>>>> unsigned >>>>> long end, >>>>>                                             int node, struct >>>>> vmem_altmap >>>>> *altmap) >>>>>     { >>>>> @@ -313,6 +317,9 @@ int __meminit vmemmap_populate_hugepages(unsigned >>>>> long start, unsigned long end, >>>>>            for (addr = start; addr < end; addr = next) { >>>> >>>> This for loop appears to be redundant for arm64 as well, as above >>>> mentioned, a single call to pmd_addr_end() should suffice. >>> >>> Right, that was what was confusing me in the first place. >>> >>>> >>>>>                    next = pmd_addr_end(addr, end); >>>>> >>>>> +               if (!IS_ALIGNED(addr, PMD_SIZE) || !IS_ALIGNED(next, >>>>> PMD_SIZE)) >>>>> +                       goto fallback; >>>>> + >>>>>                    pgd = vmemmap_pgd_populate(addr, node); >>>>>                    if (!pgd) >>>>>                            return -ENOMEM; >>>>> @@ -346,6 +353,7 @@ int __meminit vmemmap_populate_hugepages(unsigned >>>>> long start, unsigned long end, >>>>>                            } >>>>>                    } else if (vmemmap_check_pmd(pmd, node, addr, >>>>> next)) >>>>>                            continue; >>>>> +fallback: >>>>>                    if (vmemmap_populate_basepages(addr, next, node, >>>>> altmap)) >>>>>                            return -ENOMEM; >>>> >>>> It seems we have no chance to call populate_basepages here? >>> >>> >>> Can you elaborate? >> >> It's invoked within vmemmap_populate_hugepages(), which is called by >> vmemmap_populate(). This implies that we are always performing a whole >> section hotplug? > > Ah, you meant only in the context of this change, yes. I was confused, > because there are other reasons why we run into that fallback (failing > to allocate a PMD). I observed that this logic was introduced in 2045a3b8911b("mm/sparse-vmemmap: generalise vmemmap_populate_hugepages()") which moved from arch-dependent codes(such as vmemmap_set_pmd() in arch/loongarch/mm/init.c or arch/x86/mm/init_64.c) to common arch-independent code(function vmemmap_populate_hugepages). I suspect it might be causing the confusion, as it may not be fully compatible with arm64. However, it does not seem to cause any bugs :) >