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 C3DBAC25B75 for ; Thu, 6 Jun 2024 09:49:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 614F66B009F; Thu, 6 Jun 2024 05:49:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 575736B00A0; Thu, 6 Jun 2024 05:49:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EED96B00A1; Thu, 6 Jun 2024 05:49:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1BCA26B009F for ; Thu, 6 Jun 2024 05:49:48 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8E51941648 for ; Thu, 6 Jun 2024 09:49:47 +0000 (UTC) X-FDA: 82199992014.04.DFC7259 Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) by imf26.hostedemail.com (Postfix) with ESMTP id B73E6140015 for ; Thu, 6 Jun 2024 09:49:45 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GjuAEcXh; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717667385; 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=m5SFAiI9V1WIFwt0VU4EfhN6CyXh9/bfQ+JmuRJbGSs=; b=m/IdIjEkjh8Zn1RmjigdvWz+yuo5XkLmVbD30K+JEDJDkUg7kERJVGZZjpnPGEBZAKrh5k 6Bo0JpDdjuw4Z9l2V/8ME3SAKhoVs+0aYbew5hkXmdvKAlXL4u7rjAi6fLiN3hIeUi1GKK mqsd+tbahRz3Y/25mt+L0QnAUsbr10E= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GjuAEcXh; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717667385; a=rsa-sha256; cv=none; b=DvS//xR4qW5F7ZRwDza0T7Y1LrZMgykN7l68prlykHldh/QAwdtbIy/uDuK1gIydKDwO/0 g/pxRT01hJSBzP5Nh0KYjPK2ogi95XTM13wUqxD3mqiO5EV9/PyySylOqVZ2hIIwROP4er saa6WispTiG3GzqyzieFCZZWZ459EIk= Received: by mail-ua1-f47.google.com with SMTP id a1e0cc1a2514c-80ac778563fso240782241.1 for ; Thu, 06 Jun 2024 02:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717667385; x=1718272185; 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=m5SFAiI9V1WIFwt0VU4EfhN6CyXh9/bfQ+JmuRJbGSs=; b=GjuAEcXhoryDJx3qGtDqyAXD57GKMNR3ID6t8SYT0tErl7ioUZEqqcA2KpJPt/rgAW qWRX6+Ruliu9JGratsSV/CQq7U5hcNdtRmK39mpecU0MyakagtKva/gmPlWsjDittBwm ybsstXphZQjSiuIhqujgTA9UofdGY7ppl/Yjt32UEpMwG3ifB+Dal+dilA66xb6edMMN YzBEgb8P1/osATEtg/pE+G+h3RkCv3O2kk86UjhTnB0m8WwuJ9faInYOYDtU8CQzFGuT PDM+CRAsYFgDpWJmv9cQvjmEB9xcB4+j/RZ+WKhg6wZ6ljFq/Wdwp2JWty3gc6VZXk1f RKFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717667385; x=1718272185; 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=m5SFAiI9V1WIFwt0VU4EfhN6CyXh9/bfQ+JmuRJbGSs=; b=kLcPZzGtamWySHFD+/ff9q/CT6gE44nL3pHHpTLg7a7iTyvpUFgN9d6oW+lqrruRXh M9tIAaTKaWjo7pZE12HFkmVueorh4b8+q1Il5Zxs4W3dVbhf1P4uyNcnq8jHfjiLfmvp 8VCOGJR8mHDCTjIDYvCznv7xW7YQnPR/nqtPrO1TBtBUeswdup/wYuGMFm2zp/JkawBf eXkr0rv/4JRBZ4KDIVC4bDH1XIddkx0kLzcnPzToDruqB9M/onBMHDDo3p+3x+AS0kIA R0jssBjrn1iWbl6TWKnDgMQYEj9MWi624ubCgs6sewlqRq75rh0QEbrevOhlFptQ18bD /LDw== X-Forwarded-Encrypted: i=1; AJvYcCVXwgOnVsI21qrKULzUA/hLgHQIkrYzdDHxLtQCLvZwXFmdCL0h2DX6g+8JFcmPxdN/DRDLnPRv1s+Eo+TNgascwsc= X-Gm-Message-State: AOJu0Yy7Llm0FsKtsq/tKe9L+N7ml3NergANfP756iN3Nh74HxdV02Cv rXfN7meTvudYUGWwBwcdXYi2cQmTBkhuGtdydXykU6x7Aqxg5k7p3rYoB0xAkX5wppW2xYtVnlN i7NREx9pfO1eKfau4+8NeByPqLcM= X-Google-Smtp-Source: AGHT+IGcONUDBOI5r+pfKRiVVGW0DOI8UpPIHDE7Yd3D8+dgFdexhME0FzGIv5cKcTMn71K2B4eDQ4MbcD2Lbrg2xco= X-Received: by 2002:a67:efcc:0:b0:486:9294:c8b3 with SMTP id ada2fe7eead31-48c04aa2bbdmr5452652137.29.1717667383182; Thu, 06 Jun 2024 02:49:43 -0700 (PDT) MIME-Version: 1.0 References: <20240606174203124_OW-VQZ_ZLm4lGEimA-K9@zte.com.cn> In-Reply-To: <20240606174203124_OW-VQZ_ZLm4lGEimA-K9@zte.com.cn> From: Barry Song <21cnbao@gmail.com> Date: Thu, 6 Jun 2024 21:49:32 +1200 Message-ID: Subject: Re: [PATCH linux-next v2] mm: huge_memory: fix misused mapping_large_folio_support() for anon folios To: xu.xin16@zte.com.cn Cc: david@redhat.com, ziy@nvidia.com, v-songbaohua@oppo.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org, yang.yang29@zte.com.cn, ran.xiaokai@zte.com.cn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: B73E6140015 X-Stat-Signature: znsszjc15993mxcz93obbr14o9t9owk4 X-HE-Tag: 1717667385-6099 X-HE-Meta: U2FsdGVkX19N4J/+aIzQ0wkEf1EJVXOnKz1r4zxJ4iOHcStphxiQXCYrughOClHFdaHsTgr2u/4Dj4DS4OdTY+Vr1igaFmDhQdl2D4ggIVyFXfWfWGqAZ4a2EC+3+jhQOGoq9vmpSlzyL8/u6NdYDezWfmXF6JZPhRp77w159+LWbYCm++0hf2grwPk6LgqBhtJVUseGHh2C6iE4SWWoUoHqZc66Ny1De/MUgRsH4LOfRLAaAsfu0NwcXUG64OZjck15DkujpgQ3chaNz9m6gmibKl9h+zGgwGvMh+b2Sk/o1/XnhdfBSPiMGQVT5apyPdHE8TGuBGeaHD9YgNe4N0sZgFB7AjkND1oeS1ZWvHpCWPA/0A9zR9m4yd64B04YdyoJictf/edgGF8tANPo8G4q1fJSE87didzNEfDzry3oueZfY3sXIoKrYh+chDeN6dUkUHCGSeN3OaHLtNEalz0GD8AYuJvnJCB3TRYT2b3Dyyb5IiogFVtaJAIxIsLtEcL7VtP4XQMc0mS3oDZXyUJcVP4bgnPJQcf3+9DN3PgH7qTdBhOLiTdQlxKsfjbcN9PjLX51firr09opmqqgARkgkBNfz2y6+lCrVU8+smHYN0MnTYFObbh4787E7EXvjo/9dT7HCsb96I4XkdN1Ek6S9giEIYiWbz8LfpHni4H9VgXvX9mpbnTNb6K4PHeTHeducL5im2T13xbaqiD73MFI/g5F6Y+vFGIGgwRZHGghZg5eVqW6D6y7ioLUwIWgwBnyr3vUlTZqeOj8nqhpfNWhkK8ikH7EuLeEx13R2DSrHRIZFpgxpbuWto/JWnFvyBxxlIneY1eUVUerrtxCYH8nbghnCv7abrIbN1cM5Ru80sKAV54my1HziqJ7C85yzQecpTvCi6ZvIcB5l9pdRZtwu+fkH4W60lMvOtCqdI+eDwGirXTWHhK3+A2fbT7ve85/+w1fau+RXPW0c46 KaB0sGAo /368MaafrjYpSkiWQrIVexD1Kv3EeLsUa0+6JpyS/PR5pb/M739uqwmz4Qslc9GYf6st7WXM84LAjz83tNAhYkGDEx79mKJRUzGxRNflQfE4MxXzGPEceotpx7mATJolxPyvaLEejiNHA/J1PdDsgYPvj1P25aUC6iROqFoFq1F08Ehh7zxuEsHLh/aj0lPiNTXQe5IRocgt3UtpopfP0bdF7flh33n8g6jeRDLj0hBeWFiTnXnYhib+9tQFhBlc2JWUMdzw/Vvg6KrKQpppyRFTDe/Ais0jA9L2wZ60q86XRG83lHP9JKrAJpTtyKn4QkhI/YROPmXpcH3e2KwcJmXIPXaxmIpgnQDQEHtTfrxU71sSY46gxTvbXDR2NGsSeId+U6mRiPlpEDRKLc7uHcLStRVJiXTgrlN8pH98xso0FyMQYjQcHtbWlwyrLbLAxaTYE/4+x7camdreN3aeB9lGoVapXxNNBxvL/K8fRsuXNo24RC53jP+a7ibD9AgF57AuYmrX8A6xI1jo= 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 9:42=E2=80=AFPM 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 the 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 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 >=3D end) is always false. shmem_mapping() is not called. > > Also add a VM_WARN_ON_ONCE() in mapping_large_folio_support() > for anon mapping, So we can detect the wrong use more easily. > > THP folios maybe exist in the pagecache even the file system doesn't > support large folio, it is because when CONFIG_TRANSPARENT_HUGEPAGE > is enabled, khugepaged will try to collapse read-only file-backed pages > to THP. But the mapping does not actually support multi order > large folios properly. > > 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 > --- > include/linux/pagemap.h | 4 ++++ > mm/huge_memory.c | 27 ++++++++++++++++----------- > 2 files changed, 20 insertions(+), 11 deletions(-) > > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h > index ee633712bba0..59f1df0cde5a 100644 > --- a/include/linux/pagemap.h > +++ b/include/linux/pagemap.h > @@ -381,6 +381,10 @@ static inline void mapping_set_large_folios(struct a= ddress_space *mapping) > */ > static inline bool mapping_large_folio_support(struct address_space *map= ping) > { > + /* AS_LARGE_FOLIO_SUPPORT is only reasonable for pagecache folios= */ > + VM_WARN_ONCE((unsigned long)mapping & PAGE_MAPPING_ANON, > + "Anonymous mapping always supports large folio"); > + > return IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && > test_bit(AS_LARGE_FOLIO_SUPPORT, &mapping->flags); > } > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 317de2afd371..62d57270b08e 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -3009,30 +3009,35 @@ 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 supported */ > - if (folio_test_swapcache(folio)) > + if (folio_test_anon(folio)) { > + /* Cannot split anonymous THP to order-1 */ This is simply what the code is indicating. Shouldn't we phrase it differently to explain "why" but not "how"? for example, anon order-1 mTHP is not supported? Otherwise, it looks good to me. Reviewed-by: Barry Song > + if (new_order =3D=3D 1) { > + VM_WARN_ONCE(1, "Cannot split to order-1 folio"); > return -EINVAL; > + } > + } else if (new_order) { > /* 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 fol= io */ > - if (!mapping_large_folio_support(folio->mapping)) { > + /* No split if the file system does not support large fol= io. > + * Note that we might still have THPs in such mappings du= e to > + * CONFIG_READ_ONLY_THP_FOR_FS. But in that case, the map= ping > + * does not actually support large folios properly. > + */ > + if (IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && > + !mapping_large_folio_support(folio->mapping)) { > VM_WARN_ONCE(1, > "Cannot split file folio to non-0 order")= ; > return -EINVAL; > } > } > > + /* Only swapping a whole PMD-mapped folio is supported */ > + if (folio_test_swapcache(folio) && new_order) > + return -EINVAL; > > is_hzp =3D is_huge_zero_folio(folio); > if (is_hzp) { > -- > 2.15.2 >