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 E7A52C25B76 for ; Thu, 6 Jun 2024 01:34:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 44FBA6B009D; Wed, 5 Jun 2024 21:34:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3FF806B009F; Wed, 5 Jun 2024 21:34:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C6B76B00A0; Wed, 5 Jun 2024 21:34:32 -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 0A7666B009D for ; Wed, 5 Jun 2024 21:34:32 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 77A5F80313 for ; Thu, 6 Jun 2024 01:34:31 +0000 (UTC) X-FDA: 82198743942.16.D62533E Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) by imf04.hostedemail.com (Postfix) with ESMTP id B20AA40011 for ; Thu, 6 Jun 2024 01:34:29 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hr2+5Yo+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.49 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717637669; 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=06T7JD9TzLagw1HoaEfo4EvOvyoWt/K/eu8qOPbaOiI=; b=Ih5L4OManhUzt11TTDfeOGWN4VOrAOTkaQlA01GVAxovr8vqxyMy24gQ7OcYoVMcHblhH+ 85R2nfKypf1EBz5JqidUWMFXRmZrc5Hyvb0jU4sy6ygeBUSW9CWaQRX6cd4cptQQw/A73v wHC4yAR4BOKS7PkN3polxeU52Dh9roE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717637669; a=rsa-sha256; cv=none; b=l3Y9d/EonLJXZV6uYh/i6fQuwPkEGRQCII1M0DC7iUUNE7L5l+KmJWrEnCke0zjBW598FA 1dTJx1+qyhOnmivNhRSlCoACzJRxs9T7yxWW2gv3o9jQf+Sb1lShEyeo+5dyVljOhecYI+ oD4KZmuv2XOs7wqXHNVg2l4DF0WOdGU= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hr2+5Yo+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.49 as permitted sender) smtp.mailfrom=21cnbao@gmail.com Received: by mail-vs1-f49.google.com with SMTP id ada2fe7eead31-48bc3314cddso164597137.1 for ; Wed, 05 Jun 2024 18:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717637669; x=1718242469; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=06T7JD9TzLagw1HoaEfo4EvOvyoWt/K/eu8qOPbaOiI=; b=hr2+5Yo+zYINMzKn4PfViioSC3MwTWpYeQwsBskQswCKnc2CD/yEuNDR3PvI/V0lWj H1WpXcNdg682EzVzdTLuw3qvVmFsXiOeKgq61LhRS+fljMtPEL+SFKGIuSxK9Ube7+8j TKsGg3xtz71fsZbFvZU6iU8V4G6iQlXeXJRnNDXQh5+1N6cQLJGFMGBHv1na16VoFxnc rz/YBDkC0rV3Y2QZdDRdOzjPv7R3Uoh9P/q1ypqChZLZvzyHhHN0DxywVxhBiDp6flzF cfQEr0wUpvkfbJ7UzkUbBQrqTf3JmBhZn1BneRA3Lyk3gtwhu8wGCaPJZOoFZ5wSP2pK csiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717637669; x=1718242469; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=06T7JD9TzLagw1HoaEfo4EvOvyoWt/K/eu8qOPbaOiI=; b=bRZfa6XcUXuPe/evaCcbiOLyx2JMJMUlfOhyeREn7QVHxkQdkDxW4KG4lXXrzZ3qye lSPQ6qjpGnVcbD9VwAk/oHCk8jjrUKDwq8iJuDc4jVaBAeJuU/QjeT8Sqc+dWR4uSVzY 9buNcpAg97vFKq6PNPzKs/PX5QBDeGnoKJykfSdg3bggY6Rhtc7MXkozvjHYh0zlfbnx 7p5SaI/DhC36J+FkpPH2qysIsBDDtx8J29QGKavSfdwr5UxdR9QrOBXRJBW0nwa8roaG UO/oB6N2xisKL5CBuXGHCdg8XRkmQ+eawAvdEjtzmTvPhj7X6yoBRoSSWSBXqhgD2kz/ ZosA== X-Forwarded-Encrypted: i=1; AJvYcCUxM3hMbS0WUb8FjWzbOIphrf+dwzHoM3u5doIISdSKfkekrmXlKkkVkC45X24ffc5uW9prbBr6i3eDifKzf7i0C04= X-Gm-Message-State: AOJu0YxDz1QQNhOFWlNvs4xhz6Nk4M94OD+zSNYgdhdWY/xHpbbdcBJu AmRBymFweAhJdTKO+pvkJT1YDq/r9Zj7V0zwhXKxqHYxpt7T1553X1ScpzJFYlSxtVm1+yDt8HC xEJThVUMZQuOVBpp0uZcH4CEPmRY= X-Google-Smtp-Source: AGHT+IFvvwHmoVJKz690HPDRcgdEvbUevNN1TCtSrXCMBvkBg5/9zEakDVu+eMDfsczVMmmtvf9T00c21CIp/iQlT+0= X-Received: by 2002:a05:6102:22d2:b0:47a:2386:268d with SMTP id ada2fe7eead31-48c048482d3mr4365244137.12.1717637668515; Wed, 05 Jun 2024 18:34:28 -0700 (PDT) MIME-Version: 1.0 References: <20240605095406.891512-1-ranxiaokai627@163.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Thu, 6 Jun 2024 13:34:17 +1200 Message-ID: Subject: Re: [PATCH linux-next] mm: huge_memory: fix misused mapping_large_folio_support() for anon folios To: David Hildenbrand Cc: Zi Yan , ran xiaokai , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org, v-songbaohua@oppo.com, xu.xin16@zte.com.cn, yang.yang29@zte.com.cn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 4qwizjpskubjkeyatk74pgo1iqqxoxfj X-Rspamd-Queue-Id: B20AA40011 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1717637669-144129 X-HE-Meta: U2FsdGVkX19aVXSA0aUFkNN4CBQh9TYfN7D74KIZSKKnXevb/G2t/mIFt0os9eGyK59CEgSiY+M969rb7M75JKbmXlW/D0VikDGk1sIVZcEp+vwlOrgy5chIBGyOxj+L+WX6W9zDurCfC0Lis8/7faKI/NaTYLpvwiJ6o4QNCwoXcNe6hD0vnGnmXx2uoAMI9paABEjLuecGwFJPF9VJq8JYSIWgloLhU41zpZPegqfy6V+CfiKmPoa9FsNJ3wTMMhIW9FuGAEB7rO/wV7NacisEkl7xOuNAcP5/ESYYGvHIDqrdNRa8m4FbDIoZbIATGLEYzYRQnUuvDO5qwQtbwMiVJKa+fFpu97i2TONNv+2WVTnfZG6IA4RBTj5LNbUhtdyIjQ+7iOb6VnPYo7JKfqILn71WxdwdaQAbTIGwkrUTAyvbjm1Y+1PNh+dtWXRTdkT7xXpQhsyLcFoivAz3I6XysA6tuJZ73ougv8ao9WgQFUDz8iK06jwyljUjQKmVaHxomqgfrkX3TxPQF84z3RPf8MertIbo/RxPs9DvazhDAFWXnkpo6T54p56Znbhlgj88aCgrJkvW6L1SlqANZvr+ac2SruaGUc7ZZgUHsJ2yQBjE4keMQJbRh+wJ/uNxqLxQ1ryFxnnVMRfQcUeomWHV55ecdtt20jiLaf4d+apPlR42B0BOVr9usIp8fMBgAn8WtlntmyYPFX4ek1r/3cWuqQoQD52zbs/YA5xYPKS12/yJwSyh9F9EoEL2XV4LyIG1umOFf3jbBws18W4aCEkrSlS/Ue3mqzBwXCfLPBd9fKM5XXtw9KPdOHQ4lVpfFEjx4NKfnNpzdraGQ4v/2EPER3PDtFOssM2aKj75KSDA9uiyg5GDLUyQxVzGgCWulNItkxYkU3MMYx0xKnOOFIRcLeJ8Vnc90EQC/0Mpqg/RPFfIOqn/iwGLPRz/s6llS/Nui6QpZwTZHa9fznt +Yyk9cKJ pVNexklNnCCdYCAJD6PDaHkyWZFsgP7cf61eD60u4vFOFT1571xS7YVFcjlYM59cwaC7upcUsN+i+U8K9/o4NhxKiolUyjpHj8wiy26BpMKqWprTBeEGwi4cUoGQ3JaLjohfsgpZH4xLYW6dY8ZAnkSJCAzwvTybbMDvQ8oAXrR7RfrELgmag/UiAtTymRsNDMDKpQCijEUmqoSecE2STeJ21zvJe3L2rj/V7bhue2FDWZju9ix8GKSOC0izwThV8bIuP91ONa3UzVimdBindnjncbyVgL6BhTETSnxWqSO/nma40UqUt9za7kAQmqxWzjCNcS3dmzQutqT8ERIHMVIG4x6t9SUmeOV0pp0VJuA5JshUzZBCwIbE2FHKtadwG30gk7CA0rMRwPfBjPUII4rouOa11qHgzKtA0yoqOAbQ5Z1FLk+4VYwlQJIPfjitm/07ChiQgJ3LzXio1DdJGlLezr/CeM+IDdJZhlngwLzVvZwM= 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 Thu, Jun 6, 2024 at 2:42=E2=80=AFAM David Hildenbrand = wrote: > > On 05.06.24 16:08, Zi Yan wrote: > > On 5 Jun 2024, at 2:54, ran xiaokai wrote: > > > >>> On Tue, Jun 4, 2024 at 5:47?PM 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. > >>>> > >>>> 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 ad= d > >>>> 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 >=3D end) is always false. shmem_mapping() is not cal= led. > >>>> > >>>> Using /sys/kernel/debug/split_huge_pages to verify this, with this > >>>> patch, large anon THP is successfully split and the warning is cease= d. > >>>> > >>>> 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 >=3D folio_order(folio)) > >>>> return -EINVAL; > >>>> > >>>> - /* Cannot split anonymous THP to order-1 */ > >>>> - if (new_order =3D=3D 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 suppor= ted */ > >>>> 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 o= rder"); > >>>> - return -EINVAL; > >>>> - } > >>>> - /* No split if the file system does not support larg= e folio */ > >>>> - if (!mapping_large_folio_support(folio->mapping)) { > >>>> - VM_WARN_ONCE(1, > >>>> - "Cannot split file folio to non-0 or= der"); > >>>> - return -EINVAL; > >>>> + > >>>> + if (folio_test_anon(folio)) { > >>>> + /* Cannot split anonymous THP to order-1 */ > >>>> + if (new_order =3D=3D 1) { > >>>> + VM_WARN_ONCE(1, "Cannot split to ord= er-1 folio"); > >>>> + return -EINVAL; > >>>> + } > >>>> + } else { > >>>> + /* Split shmem folio to non-zero order not s= upported */ > >>>> + 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 supp= ort large folio */ > >>>> + if (!mapping_large_folio_support(folio->mapp= ing)) { > >>>> + VM_WARN_ONCE(1, > >>>> + "Cannot split file folio to = non-0 order"); > >>>> + return -EINVAL; > >>>> + } > >>> > >>> Am I missing something? if file system doesn't support large folio, > >>> how could the large folio start to exist from the first place while i= ts > >>> mapping points to a file which doesn't support large folio? > >> > >> I think it is the CONFIG_READ_ONLY_THP_FOR_FS case. > >> khugepaged will try to collapse read-only file-backed pages to 2M THP. > > > > Can you add this information to the commit log in your next version? > > Can we also add that as a comment to that function, like "Note that we > might still > have THPs in such mappings due to CONFIG_READ_ONLY_THP_FOR_FS. But in > that case, > the mapping does not actually support large folios properly. > "Or sth. like that. +1. Otherwise, the code appears quite confusing. Would using "#ifdef" help to further clarify it? #ifdef CONFIG_READ_ONLY_THP_FOR_FS if (!mapping_large_folio_support(folio->mapping)) { .... } #endif > > -- > Cheers, > > David / dhildenb > Thanks Barry