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 95AB6FA373F for ; Fri, 13 Sep 2024 10:36:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D07AE6B00D5; Fri, 13 Sep 2024 06:36:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8F486B00D6; Fri, 13 Sep 2024 06:36:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B57146B00D7; Fri, 13 Sep 2024 06:36:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 951506B00D5 for ; Fri, 13 Sep 2024 06:36:56 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4B5B2141A87 for ; Fri, 13 Sep 2024 10:36:56 +0000 (UTC) X-FDA: 82559362032.19.82BA197 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf04.hostedemail.com (Postfix) with ESMTP id 8AC3240006 for ; Fri, 13 Sep 2024 10:36:53 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf04.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726223785; a=rsa-sha256; cv=none; b=Wl1CT76BxxoQdqxdyG25wjD3GZRl/Lp3QPERF/4sBffkbmtzJU4UHxvqQXc9kb2kI1wPrW P52LExLjM3aa0ZquEaPK6Gk3F0CAhektKbhcqgy7t4jXA+lIN8EerXrawudzsu6VYyvcdP Xr3dem8LKG/9J6JBGQnhBpecNt8GVmc= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf04.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726223785; 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=hW1Ix8UrUetXnWE0XXpsmKURxnwf/c6rd0g3Ao2kfq4=; b=EWhFNkR2U0lDimehvBKTe5Qoxcnu0R6drmVWWZRzQlh2R2FOQXotUwWAjLgGiy5zFzdBoP S0iFNTFRdmyTlyn7xkNG9R5BU1gzVloqjbXqeVyjyaAbkJWeRggDabuIjjONOjvuDP36AO jnBlCvrTmQH/SZ95EE0OAG4K97i067E= Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4X4rM53kGpz1j8VN; Fri, 13 Sep 2024 18:36:17 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 406631A016C; Fri, 13 Sep 2024 18:36:49 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 13 Sep 2024 18:36:48 +0800 Message-ID: <9b4fa269-8e1f-4f14-a737-b6b0697d83b5@huawei.com> Date: Fri, 13 Sep 2024 18:36:48 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: set hugepage to false when anon mthp allocation Content-Language: en-US From: Kefeng Wang To: Andrew Morton CC: Ryan Roberts , David Hildenbrand , , Barry Song , Hugh Dickins , References: <20240910140625.175700-1-wangkefeng.wang@huawei.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspam-User: X-Rspamd-Queue-Id: 8AC3240006 X-Rspamd-Server: rspam01 X-Stat-Signature: 81rux6gkky61amp9ud51ejwzdbtrp6oq X-HE-Tag: 1726223813-300839 X-HE-Meta: U2FsdGVkX18ZvVAb4EbYLjqSqVfh1Y+kvHT/HM5FGl1Gg5aHel+IlEHmrAB/4NMrfz6q4Uc8gcTwNgouHhwFQSAs5rTeYIJaARtVW5H1Crw1ri7kW++y8pUSZu8qIEFU+aGasiUVWmdHKTJnzl9XoBxmRuHi+1kSMbT0fPm2rc4/u2lHAEYtRc+P0bLA1joS8iEjkonPmkx4OkLH2RwtNlujBFnc/7lQrU8WGIDrMt/saF7iQ0lk55qfkIZnAhD8xha70q1ECUBWrk1K3mXVaAkAEzZWrpXbCjfhWUftP5nPutrrP1NPqr3EbPM3eXTjfOqKhIeP0/+Z1xBlJaz6mIyqr9/S2XkeIekgxm6YlIjtpYDIV9YX4OxiOAnwwLvx/Ops0xJDf91SrD31rip7ZN3YJRaYndpik9o++mvJLW63wFpuTwcnBFMzkOgFmHMI+QNytQ6LwPzewRBGNlPvEYD3OUYSXXDE+TElx1RgVoRLqsqbeDqRWgbFtV/OZYCqE5jSgwQmpOljPS8rWSUqI3TXL93wot4y7K5mimfAA5SFMWXOrLpqcyZGYp5DlCuFaCJKFexylForLo16aZBHdG0Gx85/YpKl14Df4uI3D/Vgwn4yoqMZNIR6dx3qwRWeaT0hapRFZGLwRn5nDl8zBez+qfnuXb0/UI2tMzMoohnyG9JyGR/a6GHvdN5VA7r2blkL9YeF8za/pZsGm3nugo2TZGVPDuevjYGFlqG8L3DZ782P4/ooYitJQJ2PcFlO2AluCZtmB+R6ffes9bZYYHj9VH0TAWfTcjtD8pYfoxk6Uot9MNygo0czMg4kkblrO5HUmDXaJSImXNaopcrEjroHZkVFlM5KrRrau9bgrh1SNJVrF2DZTgsUNPWqTCuoScYQpfI9x21ZFX4JoYQhoyPR3AbEVWuqYatUr0FWLLrmUkfNIE/8e52K8b8pHJx2spp2ziEOG3vYy15mdhp 3li/pn3G Z8GYOp9jjj8YdPszr6liiqsUp8m+fSTyjvo7qMQ4qwM4Cj1WPmmwzMKuEq+YPEvh4/lSKr3rvc1WbgsLFvSWOdXVAr6jYfgX6pEDEw2q0AgRN3Tbh3mVMQsbtkXxy5pLoOk3yc0AiDRYTlDlvRuj2JpjoEXsehWCL1wah1sPZJGUv1MDaVVAHMeXD1rYoL+RBbrhnemHeFI6iEyMlk4sy23QSJA== 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: Hi All, On 2024/9/10 22:18, Kefeng Wang wrote: > > > On 2024/9/10 22:06, Kefeng Wang wrote: >> When the hugepage parameter is true in vma_alloc_folio(), it indicates >> that we only try allocation on preferred node if possible for PMD_ORDER, > > Should remove "for PMD_ORDER", I mean that it was used for PMD_ORDER, > but for other high-order, it will reduce the success rate of allocation > if without ddc1a5cbc05d. > > >> but it could lead to lots of failures for large folio allocation, >> luckily the hugepage parameter was deprecated since commit ddc1a5cbc05d >> ("mempolicy: alloc_pages_mpol() for NUMA policy without vma"), so no >> effect on runtime behavior. >> >> Signed-off-by: Kefeng Wang >> --- >> >> Found the issue when backport mthp to inner kernel without ddc1a5cbc05d, >> but for mainline, there is no issue, no clue why hugepage parameter was >> retained, maybe just kill the parameter for mainline? Any comments, fix in alloc_anon_folio() or remove hugepage parameter in vma_alloc_folio(), thanks. >> >>   mm/memory.c | 2 +- >>   1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/memory.c b/mm/memory.c >> index b84443e689a8..89a15858348a 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -4479,7 +4479,7 @@ static struct folio *alloc_anon_folio(struct >> vm_fault *vmf) >>       gfp = vma_thp_gfp_mask(vma); >>       while (orders) { >>           addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order); >> -        folio = vma_alloc_folio(gfp, order, vma, addr, true); >> +        folio = vma_alloc_folio(gfp, order, vma, addr, false); >>           if (folio) { >>               if (mem_cgroup_charge(folio, vma->vm_mm, gfp)) { >>                   count_mthp_stat(order, >> MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE); >