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 154A5CEDDA9 for ; Thu, 10 Oct 2024 01:13:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F2946B0082; Wed, 9 Oct 2024 21:13:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 97B526B0083; Wed, 9 Oct 2024 21:13:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81BFF6B0085; Wed, 9 Oct 2024 21:13:22 -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 60FC46B0082 for ; Wed, 9 Oct 2024 21:13:22 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 72F14121160 for ; Thu, 10 Oct 2024 01:13:19 +0000 (UTC) X-FDA: 82655919444.27.E75488D Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf07.hostedemail.com (Postfix) with ESMTP id 9F3B940005 for ; Thu, 10 Oct 2024 01:13:17 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728522663; 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=mZ/TN5N0QYw1v7K6eThCPaq0Mq3GwOJxyBBOUI+d7VI=; b=L9qUaqOi9AAwJI/Znybh9DVkyG047ZCB7ELNnKvmwip22JDbUPAlsqvgboKPoNHGF5URWd DJPrSuqTbqu2ISoC39nzHUfiZiJpjox/3MtmoVgnLIKUixyKLibquEZisnY8iYlYv2/0ai rfuBCAdNFvYeY69AMlYepE9ccMwvXA8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728522663; a=rsa-sha256; cv=none; b=ZgWhRlepNn/f6G/Lo01IPYVu7yuD/17mI8ARPSZbqfhbyEFGVVA/st6+m40Tv1qB7rIuau B2CHfjNwDrDahfCg4o2uR8LVd6FH+ERhfaFwQe5VrIGH7PwKMqOm049mY2SGOPg8Mnx91G M9hRREEKVfD4oXKFhXEgZfbUjlKTCOE= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=pass (imf07.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4XPBYT3VVYzyT2H; Thu, 10 Oct 2024 09:11:57 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 6FE801800CF; Thu, 10 Oct 2024 09:13:14 +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; Thu, 10 Oct 2024 09:13:13 +0800 Message-ID: Date: Thu, 10 Oct 2024 09:13:13 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: set hugepage to false when anon mthp allocation To: David Hildenbrand , Ryan Roberts , Andrew Morton CC: , Barry Song , Hugh Dickins , References: <20240910140625.175700-1-wangkefeng.wang@huawei.com> <9b4fa269-8e1f-4f14-a737-b6b0697d83b5@huawei.com> <443f9571-37dd-47eb-b8f3-91b4e779bb9e@redhat.com> Content-Language: en-US From: Kefeng Wang In-Reply-To: <443f9571-37dd-47eb-b8f3-91b4e779bb9e@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemf100008.china.huawei.com (7.185.36.138) X-Stat-Signature: bbpdkkihw5gtzb5c8mpq7y9zf9ckgf8r X-Rspamd-Queue-Id: 9F3B940005 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1728522797-52893 X-HE-Meta: U2FsdGVkX18WrtGHZQpLDwhbklqcryU59L56k3hw/xlJ62zxrcgX4Y9pDqpJo/CivyIgBc1yslzrWKo9YZIRVb9ovUpnpnyhwF+Vpajc2H2jAekQnUXoqjsM+lFeRHReYgkG1cxpX3gWOfEn0OiccqAk0cHkM85QeIP6CSAUM+wCgKjB1XKjY8yFszWYV5gvN8s18iuiHAG6Iid+RZ9LW4dwp86kYjEsfqI7KG8QBgWNs0vthmgUCy9u8e509StA3bFEhQp/4xkjXaAJEFbbbnbDStJj8TG/qiwRIb806rsgqaroMcKyxP7u0TpMoeNcTHJ74Mcvt10JkxM/au0ds6FrqGexhC63dwmUVecPcVVVsUro9g/wYUxJIwPRq8Mva2Fv6Bqvf/AASk4U1NTT/Zta9Drz8dlPGSQHExp2DemM7fe0HW68pVhVdzeYJl8A7UdhewFehsTrl3SbDLvrFcl6W3CY55n8CojX+i/VznkLTfPLa/1ndMmRf6bgLGSEs8b6MTKwaTEvpTJJswruLxhP/9+5BOZolUV37zB8DjL9Q3m9jDAegsu2nxl1ANthu37mC7NoFXg2MCb+l0ZD0QIgtnyrQWjyPN82cM82l7lz4ygZVwvi5me/aAn/LpWQo/3CBYhHdGzH3BJeIjUhAq59ST/RAfvu4tMYt0OwNEbiEzpCSXZSkMILPtaSyMEFifmETjfZjsEj8NNSboPkhoskJkN8aJqhXDR0+woGSJygeWlGrvBiY+ijo39O73BTMDuVuBulYEVPf+iYWxZuggKWg50FixMqYnOvf3dukkvUGxaqi7ueNFvK0s7jz0dYkCG4Wgiyg7mvI5nMAu9kbX+AwLeOwRPp3E8XIqWNSImWWNu7S3q2UdPG9ofm29Hvw3U3TP5/gxi+++ZplGVgLAazTi/vXYaYaCi6kPZtMI+DqPTtIHXlOr+GC4YLgTz4oycDZGLoE7zRm0JwUwr LxUMD02t hdZFFnNd4em0o1VycmFvatFsqApJHHW1+YdvR+UdFceCOUwyyMtYFAGfJJ245X8aCUfUYeD4JboliKLgrXhMAmZYlXj5aUbjZynDRx8wKQ5PHZdhmn/JBiraIjrmCFhBGD4qFJWT/wZgngRvth0f4kTOckk6DjrQAHLOPRIEjjtaqly7Muj7/zEMQRF/4Y+glFUli 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 2024/10/9 22:28, David Hildenbrand wrote: > On 09.10.24 12:44, Ryan Roberts wrote: >> On 09/10/2024 10:15, Kefeng Wang wrote: >>> >>> On 2024/9/13 18:36, Kefeng Wang wrote: >>>> 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. >>> >>> * vma_alloc_folio - Allocate a folio for a VMA. >>> @hugepage: Unused (was: For hugepages try only preferred node if >>> possible). >>> >>> Since hugepage won't be used in vma_alloc_folio(), maybe just delete >>> this >>> parameter? >> >> Sorry for the radio silence. Given the param is no longer used, I >> think it would >> be cleaner to just remove it. > > Agreed, no dead code. Sure. > >> >> It was set to true here on purpose though; the aim was to follow the >> pattern set >> by PMD-sized THP, which also sets it to true. And the aargument was >> that the >> benefit of having a huge page would be outstripped by having to access >> it on a >> remote node.>> >> Now that the parameter is deprecated, do you know if the policy is still >> enforced by other means? > > Right, it might indicate a bug. So figuring out why there are no users > left would be interesting. Maybe it was all on purpose. > Before v6.7 ddc1a5cbc05d(mTHP from v6.8), it checks hugepage parameter (only for PMD THP), after that commit, we check the order == PMD_ORDER, so no different for PMD THP, but for other high-order, it doesn't follow the pattern set by PMD THP. if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && /* filter "hugepage" allocation, unless from alloc_pages() */ order == HPAGE_PMD_ORDER && ilx != NO_INTERLEAVE_INDEX) { "The interleave index is almost always irrelevant unless MPOL_INTERLEAVE: with one exception in alloc_pages_mpol(), where the NO_INTERLEAVE_INDEX passed down from vma-less alloc_pages() is also used as hint not to use THP-style hugepage allocation - to avoid the overhead of a hugepage arg (though I don't understand why we never just added a GFP bit for THP - if it actually needs a different allocation strategy from other pages of the same order). vma_alloc_folio() still carries its hugepage arg here, but it is not used, and should be removed when agreed. " For Hugh's changelog, it seems that we could just remove it, but since no mTHP when made this change, Hugh didn't take into account for other high-order folio allocation.