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 18D1AC27C54 for ; Wed, 5 Jun 2024 02:57:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A1AF76B0089; Tue, 4 Jun 2024 22:57:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C9456B008A; Tue, 4 Jun 2024 22:57:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B8066B008C; Tue, 4 Jun 2024 22:57:26 -0400 (EDT) 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 6DB976B0089 for ; Tue, 4 Jun 2024 22:57:26 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D5DAAC0EFB for ; Wed, 5 Jun 2024 02:57:25 +0000 (UTC) X-FDA: 82195324050.24.C9A026B Received: from m15.mail.163.com (m15.mail.163.com [45.254.50.219]) by imf22.hostedemail.com (Postfix) with ESMTP id 637A5C0002 for ; Wed, 5 Jun 2024 02:57:21 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=163.com header.s=s110527 header.b=nq0cdJiG; dmarc=pass (policy=none) header.from=163.com; spf=pass (imf22.hostedemail.com: domain of ranxiaokai627@163.com designates 45.254.50.219 as permitted sender) smtp.mailfrom=ranxiaokai627@163.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717556243; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Rleg+P2oOGADZV9ADR3po7+nIwArg90kr4FeqXQZGrU=; b=qE10YjtE/cxNNj3BCMMO0aUkLdgMGWhB1swq1/6ZhoG18OHEUsXnoL6Ytj4VLaazGNmun0 lprKuJmWruMSBrdFgmDTH4yct3SX2/ImCiEdRBn2Fb6AOgDea2CLjoc34cCkKO4W+V3w57 tKdy6PAuK3Xxf4j9004lP16ckPGdCf8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=163.com header.s=s110527 header.b=nq0cdJiG; dmarc=pass (policy=none) header.from=163.com; spf=pass (imf22.hostedemail.com: domain of ranxiaokai627@163.com designates 45.254.50.219 as permitted sender) smtp.mailfrom=ranxiaokai627@163.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717556243; a=rsa-sha256; cv=none; b=y2uq8aczZFYBHvvBTRWueKQ4U7RMzhae+hGqQqVbslV6cAkz1FEHqKw/PSB7At4bbHD9v3 Kp7Aw1FOaztLVaha65masJTQ5U5AGxriWywiSZTAzr3/DcJsMwGgEZdcw0WxMz+Se0eiOZ OCC4l//JkELzhdmQohpvH5JLJCFQ9rU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-Id:MIME-Version; bh=Rleg+ P2oOGADZV9ADR3po7+nIwArg90kr4FeqXQZGrU=; b=nq0cdJiGJ84burWXE93Cl emmoQhno1X/SWzUaEumYKMOcYlwlRdW5Fa5VCDJRyINU/2yC05y3cqzJ+DSvE2ud Fr95QBNYuxz+VmMFGBSz07gjjftq3ZyE9sOT9S9S4DoPj36prJzeqfxH4h6tlhNp n64BuJn2VEd4HduRwSUtb8= Received: from localhost.localdomain (unknown [193.203.214.57]) by gzga-smtp-mta-g0-5 (Coremail) with SMTP id _____wC3LwT5019my8syAg--.63924S4; Wed, 05 Jun 2024 10:56:58 +0800 (CST) From: ran xiaokai To: ziy@nvidia.com Cc: akpm@linux-foundation.org, david@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org, ran.xiaokai@zte.com.cn, v-songbaohua@oppo.com, xu.xin16@zte.com.cn, yang.yang29@zte.com.cn Subject: Re: [PATCH linux-next] mm: huge_memory: fix misused mapping_large_folio_support() for anon folios Date: Wed, 5 Jun 2024 02:56:56 +0000 Message-Id: <20240605025656.889177-1-ranxiaokai627@163.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wC3LwT5019my8syAg--.63924S4 X-Coremail-Antispam: 1Uf129KBjvJXoWxZry5Jr4xJF4xKw1fZr17Awb_yoWrXw43pF y2gFnayFWkXrZIkr12qF4kKr1YvrW8Xa4kZay3XwnxAasIgF12kFWUJ3W8uay8uryxJr4I va1UXFyagF98taDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRoKZZUUUUU= X-Originating-IP: [193.203.214.57] X-CM-SenderInfo: xudq5x5drntxqwsxqiywtou0bp/1tbiMx70TGXAloslvQAAs1 X-Rspamd-Queue-Id: 637A5C0002 X-Stat-Signature: dece1topb988ts4hzicaendmt3kw1jgq X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1717556241-506071 X-HE-Meta: U2FsdGVkX18brHmYmrd/Ys2mUS1J4I8bUA0jtpxexxj+1De1WpQSBIl7240Djlgz7GoLSr836YWz3s0+pvs/FbsWUzcA6nonJ7q4hZG3KJWOHm7nKmWKI4LbLvVgms/ekq1OAwdRqY79IrIGGShXkBm9n1KffJ2I4rDL/D34iQjxy3lFVv7Hi9NNQOyC/xh2bfKD6QRyElBiG5lljWw09svpH79rx3+t9l9lJ6k4Cq4fo+4DXWM69ktX/jhb7k/LJJ7po3TmGej1qMtR2oNy1SfOo/dq9tVO81aLhHoebv03v5qRL25bhOnsd3L+p9gPo6IJ3AGh49NZcYlpdSeT3mI0Ne2ePejNT0fXcnRtDRMG80HxZ/FlQpDuaGDUg1f3mcNnjQZLu3vIwNicGIwkW/PIdUx7diZ6OYwLyF4Z+wE0Xh3d3MmsgxWgaS7DiCygfa2qasXwb4GDZ3UkS3a5jbwLidMfRmmCz42xH9IHv9wlUcboM+qwgzrToGux+8Tp/RsyPS/U+LK0Dj5qc2l25v+jz3BhfJc37uvAJNGkOETD3Nkk4sXSkIbxtbGZzbVup5cXVZVCxpXTq8HOiJ0GhDw2EPtW67tAheyUUIDfHVDdytyJdOQKH0nwNlBvr97efUldaymhCG1SbDg0OI4HhRARMxKcwnG0GhuYxs0EMfnjQ/JaihRIp32ai/zVxTsjwwXpo0sAgJe+qEKztwIfiDVPxbxw/aIEDwpxB7U8W2/1ImkvcqED9D9+LX6QX/ntEQQp8b+GkDwvo8aScdGSvBe4BB4HcDgf49GKm7dxfLI/4IWW1F2LwepldGkTmHK+NCVdvfYj0vEcyLV2jQZM/Alxb20ovEf24rmPMTpvcJU705iyi58Va1nLBknk8VfeZugEtn4xJQkbHsgWA50QLAAvsdk8kNcS0yjPrRfykqG+5NDDQ52HarMwybOniZ3LEDnMDIhraNiTRs7B1YC HQkdJrR+ CrouzMSiwh+8Av99iGR8HdCCsZtrki0m8nx0jLl8IR/e2zzDW6fpHMV8MXxLoPA1dsis3o1e0bXLX9v3R6kchn7HCyXPHqp4XsErCBR3ny6tAONRsl1n9CfEfK8NjQdHlUiFSu9Nw9bJNm7z3T3/pV3ROmRjKJd7sNQSgzwZmPx1pBy1Ak3hJv4hBvxDLgPIKwmiAuYMSOQk43fdeGtu8i8pgMxNfVsGDSTiTJN0Pi0lNk8aZY8npKlCJ91sXU8nk6+DCnmO6V/JRjOOUzeb2+m2NEPi4AKkmAA9wqYjD7JIr5dGK6ZAPHsFFeovHybJ+dwqhkDLSY8oz577v8mkCq4JBPrgBf8PkhRkbJ51ORBQuryOTb/zn5USIMcALMm+dSdSqv15HS9DX9eG1T3cuaBUhZEZV8/rN+FU0uukA1gtY3+8DJHlqs8N7poNFhZsKWZMvWnqslS69srfg8BPygaY7uA== 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 4 Jun 2024, at 0:57, David Hildenbrand wrote: > > > On 04.06.24 07:47, xu.xin16@zte.com.cn wrote: > >> From: Ran Xiaokai > >> > >> When I did a large folios split test, a WARNING > >> "[ 5059.122759][ T166] Cannot split file folio to non-0 order" > >> was triggered. But my test cases are only for anonmous folios. > >> while mapping_large_folio_support() is only reasonable for page > >> cache folios. > > > > Agreed. > > > > I wonder if mapping_large_folio_support() should either > > > > a) Complain if used for anon folios, so we can detect the wrong use more easily. (VM_WARN_ON_ONCE()) > > This is much better. > > > > > b) Return "true" for anonymous mappings, although that's more debatable. > > This might fix the warning here, but the function might get wrong uses easily. yes, maybe we should rename mapping_large_folio_support() if we choose b). > > > >> > >> In split_huge_page_to_list_to_order(), the folio passed to > >> mapping_large_folio_support() maybe anonmous folio. The > >> folio_test_anon() check is missing. So the split of the anonmous THP > >> is failed. This is also the same for shmem_mapping(). We'd better add > >> a check for both. But the shmem_mapping() in __split_huge_page() is > >> not involved, as for anonmous folios, the end parameter is set to -1, so > >> (head[i].index >= end) is always false. shmem_mapping() is not called. > >> > >> Using /sys/kernel/debug/split_huge_pages to verify this, with this > >> patch, large anon THP is successfully split and the warning is ceased. > >> > >> Signed-off-by: Ran Xiaokai > >> Cc: xu xin > >> Cc: Yang Yang > >> --- > >> mm/huge_memory.c | 38 ++++++++++++++++++++------------------ > >> 1 file changed, 20 insertions(+), 18 deletions(-) > >> > >> diff --git a/mm/huge_memory.c b/mm/huge_memory.c > >> index 317de2afd371..4c9c7e5ea20c 100644 > >> --- a/mm/huge_memory.c > >> +++ b/mm/huge_memory.c > >> @@ -3009,31 +3009,33 @@ int split_huge_page_to_list_to_order(struct page *page, struct list_head *list, > >> if (new_order >= folio_order(folio)) > >> return -EINVAL; > >> > >> - /* Cannot split anonymous THP to order-1 */ > >> - if (new_order == 1 && folio_test_anon(folio)) { > >> - VM_WARN_ONCE(1, "Cannot split to order-1 folio"); > >> - return -EINVAL; > >> - } > >> - > >> if (new_order) { > >> /* Only swapping a whole PMD-mapped folio is supported */ > >> if (folio_test_swapcache(folio)) > >> return -EINVAL; > >> - /* Split shmem folio to non-zero order not supported */ > >> - if (shmem_mapping(folio->mapping)) { > >> - VM_WARN_ONCE(1, > >> - "Cannot split shmem folio to non-0 order"); > >> - return -EINVAL; > >> - } > >> - /* No split if the file system does not support large folio */ > >> - if (!mapping_large_folio_support(folio->mapping)) { > >> - VM_WARN_ONCE(1, > >> - "Cannot split file folio to non-0 order"); > >> - return -EINVAL; > >> + > >> + if (folio_test_anon(folio)) { > >> + /* Cannot split anonymous THP to order-1 */ > >> + if (new_order == 1) { > >> + VM_WARN_ONCE(1, "Cannot split to order-1 folio"); > >> + return -EINVAL; > >> + } > >> + } else { > >> + /* Split shmem folio to non-zero order not supported */ > >> + if (shmem_mapping(folio->mapping)) { > >> + VM_WARN_ONCE(1, > >> + "Cannot split shmem folio to non-0 order"); > >> + return -EINVAL; > >> + } > >> + /* No split if the file system does not support large folio */ > >> + if (!mapping_large_folio_support(folio->mapping)) { > >> + VM_WARN_ONCE(1, > >> + "Cannot split file folio to non-0 order"); > >> + return -EINVAL; > >> + } > >> } > >> } > > > > What about the following sequence: > > > > if (folio_test_anon(folio)) { > > if (new_order == 1) > > ... > > } else if (new_order) { > > if (shmem_mapping(...)) > > ... > > ... > > } > > > > if (folio_test_swapcache(folio) && new_order) > > return -EINVAL; > > > > Should result in less churn and reduce indentation level. > > Yeah, this looks better to me. > > Best Regards, > Yan, Zi