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 A2C61C25B78 for ; Wed, 5 Jun 2024 02:21:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34AEA6B008A; Tue, 4 Jun 2024 22:21:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D4126B008C; Tue, 4 Jun 2024 22:21:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1750E6B0093; Tue, 4 Jun 2024 22:21:10 -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 EDC036B008A for ; Tue, 4 Jun 2024 22:21:09 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 719DE1612C4 for ; Wed, 5 Jun 2024 02:21:09 +0000 (UTC) X-FDA: 82195232658.03.3C0DC24 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.5]) by imf06.hostedemail.com (Postfix) with ESMTP id 93D52180006 for ; Wed, 5 Jun 2024 02:21:06 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=163.com header.s=s110527 header.b=JOz8422U; spf=pass (imf06.hostedemail.com: domain of ranxiaokai627@163.com designates 117.135.210.5 as permitted sender) smtp.mailfrom=ranxiaokai627@163.com; dmarc=pass (policy=none) header.from=163.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717554067; 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=99UK3SS0coifAlgek0C0Ovd66JCCH+0Fhwar14jUuug=; b=hMSx/m9HORmmiyE7nqclM2hWAfyigl2V1Ongqg3CLlmzNDczaZPYgiL1Wmr5ipj57bYtKK /Z/2XDt9MPoVl/M5Wc78SYeS/Owx2qpFHikRJQjY5oFyi5sjtMqQnUAGMalqn0lkR/pdze uzHfUbxyHaVScFXwv03ndVFeEwoOozA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717554067; a=rsa-sha256; cv=none; b=itsx74jJHCv/CUnPd4IV8Kx/gTaOwbDu/3a2nSAM+dwfkSJ8pAbVg5zzYB34qD3106dcGx V0NolqQtWL/OBCJCmTmqCQwQAVWTsEcjyDcNPxFNiPFBUZHhpt3MvlNN5hTBacf1ygwYHH yO8F5oyPxiag8qgN+J7lx80MZVoUa88= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=163.com header.s=s110527 header.b=JOz8422U; spf=pass (imf06.hostedemail.com: domain of ranxiaokai627@163.com designates 117.135.210.5 as permitted sender) smtp.mailfrom=ranxiaokai627@163.com; dmarc=pass (policy=none) header.from=163.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-Id:MIME-Version; bh=99UK3 SS0coifAlgek0C0Ovd66JCCH+0Fhwar14jUuug=; b=JOz8422UqF4y12MhdI7Et lvvWapEK9ZQJU2hQfpblOuw+sH+e3/67SrafWczT5optIR+7BvaVIb26Asy9u0Xa PXq4z4nF3zy7gb+Ir5osyFz0KQQGRHuzisRvq75yrO/uwCmXPSuINVvKr5FZFokE e+bqCVP03/fHLMG+GZva+k= Received: from localhost.localdomain (unknown [193.203.214.57]) by gzga-smtp-mta-g1-1 (Coremail) with SMTP id _____wDXr06Dy19m1Y57HA--.24429S4; Wed, 05 Jun 2024 10:20:53 +0800 (CST) From: ran xiaokai To: david@redhat.com Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org, v-songbaohua@oppo.com, ran.xiaokai@zte.com.cn, xu.xin16@zte.com.cn, yang.yang29@zte.com.cn, ziy@nvidia.com Subject: Re: [PATCH linux-next] mm: huge_memory: fix misused mapping_large_folio_support() for anon folios Date: Wed, 5 Jun 2024 02:20:51 +0000 Message-Id: <20240605022051.888955-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:_____wDXr06Dy19m1Y57HA--.24429S4 X-Coremail-Antispam: 1Uf129KBjvJXoWxGr45tryUCr1UZr4rWr4kZwb_yoWrWw47pF W2grn3tFWkXrZI9r12qF4jkrn5ZrW8Xa4kAay3XwnxA3ZxGF429FW7J3Wruay7uryfJr4x Xa1UXFy3W3Z8tFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRrb15UUUUU= X-Originating-IP: [193.203.214.57] X-CM-SenderInfo: xudq5x5drntxqwsxqiywtou0bp/xtbB0gn0TGWXyKdRAQAAsu X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 93D52180006 X-Rspam-User: X-Stat-Signature: t3usdrhri5yaejfi6xpt1okry4x41n1r X-HE-Tag: 1717554066-630864 X-HE-Meta: U2FsdGVkX1+LxXzVpzmdI88b/lQNcIqeK5Rq36+z9f1Vb9msMf763e1i7cO7N7vy0hOokYulZeRf+mO68zHcE3n12sJp5eec9zY03aobiE2yuioE4aAk+EofqcBi5LiSKDeFytbUfoaeNEzU60hqBKG1Mfxm/4whGpCeufWBtIFrdDcApVvK3YVWsYxdeIti5eAv8GSwRAMwCkdhS6qdJD/an4/ScebYYrp8ziERzYLrAJ5AxiBxBBlb4XI2Kj3Yzt9xMmkD0hzsTzoiX5cINnMlqspZXSLsvNvRIxec4iUmuo5i/66I76Wk2J+UzPeCEAiEz7AabYgR5sibuwZmBVDgFw6DEqDD40AGGZZQ16p5Nkyj9zKDBZHAd92b+rHItjbTqZYmx1cYepcEH8F5hWtV06dCn0ehq2KzOhrkSGhYO2KNeE731fQ/rVQz2qErxwfDoGDm1IsZidnJ4I1ohPrROACNKWxNXAbpSkenn+LTOQwFQ+CtqHsS8KYDTl36RSGI5KO8LDrxVtCVTPRAm24Yz6GTJlpLytPJjZ9OvBhQECUtU3zPLCFwW5xc8hwcQHYNLEDfPBnWltoc/boPSrha7IY1fMPx5u3eiQccohQyg2iCkSlUkuPEcwipTRTHjZTPRi3BSiNusEmehzvTaibp/IKTU6UXAgbi3aqOa+mBFRquSPUDy0MwdgK5RK0Wo95rMYo9MG0OWpv6ysD5lWGA3lLshuAfP5a2xXnLwp+wsfW3P+FPk0GCdeTfvPOXzdo8g4h7tLKGHqYdDbPXopQnXKZ6DlQWpiuE5e6wyWFo2o1RaZvrVecG1akLJs7UFHLj+evoB/VfgqR+vBJuX/ftqpySaaKAV0Q4+Svq/0hx3ZL14f/aeCubH/uWdjN6Dm3hseJD+jn9iOaahJP1fZ0ks2esrqOrTPsRzvQoFNtRWrUwnbqyZlNn9PfCVCBT5gqVGuNG2P97+/q0hlv jQ4dye3e tRp6Rf4fm6GJMjy8Y8lb7PaGKo/5xWb3IKMGfKsDsQG8Xuk+JQIi9RE9EwZfo06J3RurknIAYj2tdddnNV2/y1INI7nMaz5SXvaFORwe4igsSMMFBkqTFplWOz/FK1oIVYlgI+eCKanDzZGOzbDdAeJaVM1iH0wLMr5owyEhAaO1wit8ogHpDA4lYtDCaPVUuvYBWvKkwiWdJOTBqdS9zpgWNYNbTM2PQn7ogR/CQAUc8Rx2c/D64wIMSqb3DmO4iou3LB/EY6bKVSrGBTb0O/BsdK3/fL2jBnes88jr71wBCeRuxNEz7IG1ebb95qZs14g3YZWwIuo0xZJ5/sIXoKEB8mbv+lAWC7fDxPr/lVQfyH3VLFvo9S8nJZ0AzidM6mFSIF73QEjMTS2vEyb6tmZOtVMO6Wv39xHsxfDG2zml/mTKTvgcpAeAl0evwBVuqvZeOSNoy6qHY4k8JblEqaaF6Zw== 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 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()) > b) Return "true" for anonymous mappings, although that's more debatable. > Hi, David, Thanks for the review. I think a) is better. But we have to add a new parameter "folio" to mapping_large_folio_support(), right ? something like mapping_large_folio_support(struct address_space *mapping, struct folio *folio) ? But in the __filemap_get_folio() path, __filemap_get_folio() no_page: .... if (!mapping_large_folio_support(mapping)) the folio is not allocated yet, yes ? Or do you mean there is some other way to do this ? > > > > 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. > Thanks. The code is cleaner in this way. > -- > Cheers, > > David / dhildenb