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 74727C4345F for ; Sat, 20 Apr 2024 04:59:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D86856B0085; Sat, 20 Apr 2024 00:59:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D35EB6B0087; Sat, 20 Apr 2024 00:59:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFD956B0088; Sat, 20 Apr 2024 00:59:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A38AA6B0085 for ; Sat, 20 Apr 2024 00:59:22 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 138DB12167A for ; Sat, 20 Apr 2024 04:59:22 +0000 (UTC) X-FDA: 82028706564.30.C8104E9 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf22.hostedemail.com (Postfix) with ESMTP id 3EF89C0004 for ; Sat, 20 Apr 2024 04:59:20 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZvluWprr; spf=pass (imf22.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=ioworker0@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=1713589160; 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=u/1dchsiKHqQnftO3k9Fm2LPLU40YwOV21SPiuYZLbA=; b=XDM4MJBZX5My9IOSNzl3ukeYWDlen5MirDlvRZsQsnstNe+QtX0PhOqpIh1S3JoCiayHKC uXxKT+h8yLG7IPtUhCDRd/wdngEPwWwJBAI/79NGHgz5027tujm2lyg8OAEMVvRlgIXf5S 1PW6ObQLzDDclO7MnT2Qj+Sylu9dECc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713589160; a=rsa-sha256; cv=none; b=QDDj371+6G/SwNndQwFFlWMV80j9MfphJKDccpYqcNpujrYY4SMEdpuHpA6jzNEYitw0+E WmjeQi5uH27lM3o2eldIeNev9VpSJ8QYQkv8O5gNKIsqjIzPr46hbqA3K7bD/3VkTLsihT O/k5S5byX4x11BiES3OMUkOB7Vkgask= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZvluWprr; spf=pass (imf22.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-56e477db7fbso4454129a12.3 for ; Fri, 19 Apr 2024 21:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713589158; x=1714193958; 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=u/1dchsiKHqQnftO3k9Fm2LPLU40YwOV21SPiuYZLbA=; b=ZvluWprr8y+clcIWX+/lVmMebWsKFC5RNCiCGkPGDDbPvFxpKbXq5SfiS/3jUroEQf fRZtmreM49ZB/oUqkhrOv54vh3vBV1GY3KIVPdwW1554m/qJbQ2BqaSs1qUMCZuY+jlz zgZd7jzvlWvf57csvrqo1xM9yhb15/zQfvsNy6/IOZT5R/fib5R1PWf7KXncTSf4kAjH qsNEhIbLYrGJJdCjjtcmrakYj0RhqEqX+YP5R62xDcw32Ah58+WiuAHRQuN+Foyo2EQo FDmTdiTLvxJsBSv7WQCIojYgZUHaxh4RYXozxUDuJuY3bpeh3XEI3QrcP8Q4SIGCSyym 3T1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713589158; x=1714193958; 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=u/1dchsiKHqQnftO3k9Fm2LPLU40YwOV21SPiuYZLbA=; b=FdfgLPwMtGwEiU/EiZASVl5EHM/t85LQaM2ZuDkHnaZ6XM03pAGmXAJagv5ItnUjL2 YNArsy4726KzHnJ82BBtYtFW5g9Xbc+C+N7mUwZWXZhmrwY1JDd3MzLiQRWPX4paAqz2 1MR5rwXw/fVk3MSnMG/65JmHKlvhLZ/PKkz3eypxJGBDKuUJOzsRnmZWKlkde4zWWW0O Ge4Hxwf4YjqqtMQa1gjhn3jMoaJpK0a9ezrR9gXvEhA9Y9ciZNNPT5Pe/iM04DdEdOH8 ZWDKgEVywwaSd1OFIWgIa7DvbzRri9idoLoI7ejOOslXzPbgS7tDaKBDCzUi78eWYjP0 HHsw== X-Forwarded-Encrypted: i=1; AJvYcCVNEB6d8I0aJa7yojC57L4XBlP/npj67EnMDROS12DKho7BDy1lbGRdJT9xQ6w6LAPgiVsShmrXBwLqCeYwwoZq/3M= X-Gm-Message-State: AOJu0YzMgeOV3eTcHBdLoE01z728hUh/aIiMEBLf2lBVsCS/NQscNti0 VboYf+Lu9DU5xakNfBGKmivU3T3kDD/+Uq5mfu0/iHvXgtdwkN/sd0D4bAp5fodivJe1yXnJWlz /qojmFsNuVa20C6zVIY6kUXTBMKA= X-Google-Smtp-Source: AGHT+IGLkDbsI//dCTQQt5xhkGJlKQ0ZNmyIyQaEarWAoM/l2VzchI4N48Ogohi0S2JVG/u4X4QB+/2xGA2IRFxt/o8= X-Received: by 2002:a50:a447:0:b0:568:a30c:2db5 with SMTP id v7-20020a50a447000000b00568a30c2db5mr1949648edb.40.1713589158444; Fri, 19 Apr 2024 21:59:18 -0700 (PDT) MIME-Version: 1.0 References: <20240417141111.77855-1-ioworker0@gmail.com> In-Reply-To: From: Lance Yang Date: Sat, 20 Apr 2024 12:59:07 +0800 Message-ID: Subject: Re: [PATCH 1/1] mm/vmscan: avoid split PMD-mapped THP during shrink_folio_list() To: Matthew Wilcox Cc: akpm@linux-foundation.org, maskray@google.com, ziy@nvidia.com, ryan.roberts@arm.com, david@redhat.com, 21cnbao@gmail.com, mhocko@suse.com, fengwei.yin@intel.com, zokeefe@google.com, shy828301@gmail.com, xiehuan09@gmail.com, wangkefeng.wang@huawei.com, songmuchun@bytedance.com, peterx@redhat.com, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3EF89C0004 X-Rspam-User: X-Stat-Signature: b53bassq69rtjy8z6paapbbiy7fki98j X-HE-Tag: 1713589160-291517 X-HE-Meta: U2FsdGVkX1/486xA0O0vjYyoihDYqJQ+zGrglbZMzqWkYJqEcW+VoxQOl9aDeeGZotGrEBbZJ4Fq5pnQAI7xyEqP8wvevwMjvhApkE6ZFCFTlyrBLuFNiIgWUAfCuiZUzx2zgBFurxyhYu1EU4uitaTyzSksZa4OzVEULSuUnHjYYjXPpud6pnp/yjdF6I2EqdA/xphqtCDkSSpcrWwKX+NzYov7UE8HWBauiEjxPPYiB2uLIdLzlB0Dh0gFY0IdJzqnUdVyl1mwswW25+tLPtBC2xqaj5pom34BOxK5iQOnovh6C/5EouaxLGUFPjj0TAJxIxL/fMLTWx3ORxybftwJ6hpALJUSHxsQuI1J7aYhxOHPqCj7h//Gui9ZOjyNo2hBhkUzOm53orJmBX2LNJbYI8A+G2fy5QT8SfdYe3VCwAvh8JPHV8M03Eo9HRxK4s+G0BdjMYbdwKCPsehvamqPz7mzjefFR3hFWDqladh/MOhlkKQJjtwWdbKwbQ43bwowC9Hoku0fzzeuV7XdywcoI5hgAWUxZYi08hlR1M4jyB/QlSCZkLjkqAcI2TpcpJ3J7XABvo/p8jJ9uhQtllZjxQx841CAryAjjKGRxjA1dR99qh8Hg3epElxuqa2qzUVf90W9zxeTuuM+h16TrU7lk2JRfhIMhSEnqWrOoursDDeyO0j+2rLcyXUr4HIRYkxqxlFMY61Q4ZrixL4LUA44KDBe2esOldd2loaTJj/T/kdJnYaVCz/WpuY9yvJLhXoFSioFnpSIqALXrwyPfe8k+sB4WsmihRHcFbEQjerSHqhv0Ak5QAgzso5rpaGIhe4ynZUEktqT28btUfOvWc4gRmE65UHZeoAnQhhhUQb4Wys6guZHkQvooO/py+INUsj6u2s4XjX5NUESQGdXoLCydYBt83Nkn1ZI4DVPKadIfqgfgKWNyg4AZqSYTUU/+8eJ7u3i50/vnMQYQOl iesnPhIl v1QMuO9AAoEKeqBmYmXdXGnjlelNrB5cPirfAP+VEQ1AH/tV18IEShAmCHzZc3VA8KMZePGKC7NZ+Jm2e8aDkMp7uNzuBfn+E7D4OCOC8LtO58mJ9C14b1bapMpFPUATNPZK58aZoU8FM53mRTf9cFoP9ME1vInwAatenR8b7FKP2SlohMRfLgK+wxvGKlZnPW+FjFl0GGzsUPBEDP2uHF840asEPGn7vdWd9BiMv2uxHHzPZvlZojgpyeyBBS5tEnqZo1faMhMjJRnixcHOvgCtdP5IT1Z1t4HY/V4Jm0KJr4vd6U0Hzvn2WFJw9XsNZSXRaSDdXD7JV8CIJ9xvxxHSdLNxurbOn5zApbOOmHGLCS3qFah94Vqvy3R5guYnr3Q6/8+hbd/62KC20fZFUkKBdwn/6/2H2sufrvSroQ6J6WLINtLStSBZOCwaeoNV0LnY+bhbuCavt/X2IOXJWRXc8TURRS3kXT9l0RHPm3Bv0NHdk9IrwfZNc25yHQmc0IWzw 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: Hey Matthew, Thanks for taking time to review! On Wed, Apr 17, 2024 at 11:09=E2=80=AFPM Matthew Wilcox wrote: > > On Wed, Apr 17, 2024 at 10:11:11PM +0800, Lance Yang wrote: > > When the user no longer requires the pages, they would use madvise(madv= _free) > > to mark the pages as lazy free. IMO, they would not typically rewrite t= o the > > given range. > > > > At present, a PMD-mapped THP marked as lazyfree during shrink_folio_lis= t() > > is unconditionally split, which may be unnecessary. If the THP is exclu= sively > > mapped and clean, and the PMD associated with it is also clean, then we= can > > attempt to remove the PMD mapping from it. This change will improve the > > efficiency of memory reclamation in this case. > > > > On an Intel i5 CPU, reclaiming 1GiB of PMD-mapped THPs using > > mem_cgroup_force_empty() results in the following runtimes in seconds > > (shorter is better): > > > > -------------------------------------------- > > | Old | New | Change | > > -------------------------------------------- > > | 0.683426 | 0.049197 | -92.80% | > > -------------------------------------------- > > > > Signed-off-by: Lance Yang > > --- > > include/linux/huge_mm.h | 1 + > > include/linux/rmap.h | 1 + > > mm/huge_memory.c | 2 +- > > mm/rmap.c | 81 +++++++++++++++++++++++++++++++++++++++++ > > mm/vmscan.c | 7 ++++ > > 5 files changed, 91 insertions(+), 1 deletion(-) > > I'm confused why we need all this extra code. If we remove a folio Thanks for pointing that out! I've added a lot of extra code to rmap.c, and we don't need it for file pages - sorry. I'll reconsider where to place this code. > from the pagecache, we can just call truncate_inode_folio() and > unmap_mapping_folio() takes care of all the necessary unmappings. > Why can't you call unmap_mapping_folio() here? Thanks for your suggestion. But this change only avoids the splitting of *anon* large folios (PMD-mapped THPs) that are marked as lazyfree during shrink_folio_list(). IIUC, in some cases, we cannot unmap the THP marked as lazyfree here, such as when it's not exclusively mapped, dirty, pinned, etc. In such situations, we still need to return to try_to_unmap_one(), and then call split_huge_pmd_address() to split it. Thanks again for the review. Lance