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 E72FCE77188 for ; Tue, 24 Dec 2024 04:20:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3CD16B0082; Mon, 23 Dec 2024 23:20:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EED396B0083; Mon, 23 Dec 2024 23:20:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB4206B0085; Mon, 23 Dec 2024 23:20:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BDB976B0082 for ; Mon, 23 Dec 2024 23:20:09 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 27DBF16134F for ; Tue, 24 Dec 2024 04:20:09 +0000 (UTC) X-FDA: 82928548626.07.C5AAD01 Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180]) by imf11.hostedemail.com (Postfix) with ESMTP id C294A40003 for ; Tue, 24 Dec 2024 04:19:31 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ZggjLnDy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of yuzhao@google.com designates 209.85.221.180 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735013971; a=rsa-sha256; cv=none; b=dC3tB6eHYnLaId5yXRuHRmVAmh8hbue+HIoVCwBYSoIOs6QZNiFiPpkyo443JFL+kI243j NwSxVIWXsHtSuDtvV0sTKOrvz47HoWHM+2UJGrefImRK9rBvw2uegIXFm9FOT2F5tCDnEo /TEHrfoSl2S49kDLY4++jtFjkrke4iM= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ZggjLnDy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of yuzhao@google.com designates 209.85.221.180 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735013971; 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=IUfVd0lAdTgJRMPzreUmsExw+KqTtyN/V60XzXsi5dk=; b=igTTvLZus/+c1zBj0WUa/uOEpLloBs7zBFUCp2RaINt05iK47EM8PkuoeG+ml07/iaJjZx IgY/b1l+WX0DPbBtrMzdcWUYld3NhBk+xlieVbLdMPTEPfi0EdrSxbkPGgz7txzAxumiZw D6ga6sHQ+aHqbzUElJ3Snyan7NjLskI= Received: by mail-vk1-f180.google.com with SMTP id 71dfb90a1353d-5161d5b8650so1389080e0c.3 for ; Mon, 23 Dec 2024 20:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1735014006; x=1735618806; 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=IUfVd0lAdTgJRMPzreUmsExw+KqTtyN/V60XzXsi5dk=; b=ZggjLnDykoF9CJtxuqCbqDCM4MNqfwU/vRMSrHXgpfW9nUsMI+j7OyDLiral3gJqwL 53TB2n6f0meClwggXFGxuNYrD7b/56759MOvsZhAvEKEBu8yb0bjA2gZs0FcruaCSar5 6KtUaiWfpzSHHCshGg8s6NEF9zxmOQUBDZDcKbAFM9TNQWG5R3Tld96Hf3oEa5U2QoTz 59oe5FOHe4VJmWYH51LWmHAIOg/71ExLeafO9rZ3Bw3zmVa0EPvXCcMD12rmiVnA4n5J KS8JQHYnSDtuaG9bM29v5A5rB4vYBkIDDOGVTY2SrtnE10ieGFvd6l8ZiiejmDiA+mS9 xAvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735014006; x=1735618806; 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=IUfVd0lAdTgJRMPzreUmsExw+KqTtyN/V60XzXsi5dk=; b=DDcGNtWWuLgsr4ETnIrXYA1MAcHMGXirWPWLtQ23NXcFw11y1w8Z5xISEFDgLrw2hy nXJ6/waw+/utVQXs7LJmmzt9f40Ooc7lkdTj63U7fWzKN6zHgdXxxl0e1sqQSXXp8f7H t8O5t46GpPbh5GiwPuB6c+qe9PFNdQjk3hNxoqP5Eo4gLXqkLivo89TfnnsbhkBFzvvg 5M0CnKge7bsAhH9ct0ZlpUln6Qw34xtX5tW4d66NUboF9YUr+KKsR5226PyD17bcZdlM Us4SZuWmXnmz1Lb5PFkMBj3EtNdoO+struvubc/gducMKBWbSMXzWdggbjr8cwzqkBT8 gcUQ== X-Forwarded-Encrypted: i=1; AJvYcCXizq50WlrAYTpFMJWRFTclCqxGcMmdVA0bpOVrueTmv3yluiyuYFwqMon6B/VoJRYdznd1pXlK3A==@kvack.org X-Gm-Message-State: AOJu0YwI4o+D5XIEdRw+CaF325drB1/xb7ZpGEjbncq7tthqJ7DKdUQr vT+ycswqZyuDWCzi9r3B+87DYt/XRNmI9GGlZjJmRfEiQk//zs0EbrQla38pujO38fBWed1rsuB Ujeey/LBHxvhmMaWMAUro+1KLm6o6nW5k+GoK X-Gm-Gg: ASbGncvb2oofekoYl9s1tVUtqfEqC/iSbHJXZfGaBVTDFDd0NiATlA7aO9umqVM4Kjd URiWfu2NNclWLaNirFZQRAelSplsJV6hI5Ssxx52UmGG/7uVpsSc9p34deUAU8jNwHspCcoA= X-Google-Smtp-Source: AGHT+IFgV7A5Bgi8FzHq3g+NT/dJnRYYorvI+4EMOImJcVYRXGMVJRLuuubVTYI1IO26EC9Ujw5tbLJFxSjD8JYsQyE= X-Received: by 2002:a05:6102:5688:b0:4b2:49ff:9786 with SMTP id ada2fe7eead31-4b2cc4680e2mr14897637137.17.1735014006095; Mon, 23 Dec 2024 20:20:06 -0800 (PST) MIME-Version: 1.0 References: <20241223082004.3759152-1-chenridong@huaweicloud.com> In-Reply-To: <20241223082004.3759152-1-chenridong@huaweicloud.com> From: Yu Zhao Date: Mon, 23 Dec 2024 21:19:29 -0700 Message-ID: Subject: Re: [PATCH -next v6] mm: vmscan: retry folios written back while isolated for traditional LRU To: Chen Ridong Cc: akpm@linux-foundation.org, mhocko@suse.com, hannes@cmpxchg.org, yosryahmed@google.com, david@redhat.com, willy@infradead.org, ryan.roberts@arm.com, baohua@kernel.org, 21cnbao@gmail.com, wangkefeng.wang@huawei.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, chenridong@huawei.com, wangweiyang2@huawei.com, xieym_ict@hotmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C294A40003 X-Stat-Signature: pwzdca8hf1mcqjs8bqj9syweejgft3y5 X-Rspam-User: X-HE-Tag: 1735013971-602329 X-HE-Meta: U2FsdGVkX19spwqRMLkAkfak92aUz2B7ai5nzmGq3cYGWmlWF8IcrcE88wcJjtcmRkZPIVhPuIdt/7aODWtaafnzkHZh8cEtKM7/zmGUGe8ScwnKEdTh0lLAoU9sUYetyYkziSa8R2P/zWClbZrSmqKsipUonN4mq9i7zK1pnDuIMIDJ1adjdlBAGn5gcuusggX+IJ412/+YTtQ/VpULIlJTjkcJi5BXxaBxEM2un1tlaEZGBkuzxNGRFN0M1KAF7P45EFVdOeusIALvTYeLG0rup0sz6oa5jPxL0ShRm3PKK2rLyanDOxhkK2vwPeMHQahC2K7OFhxWQbLxIp6SwTMJAXGOxXln+uk0JeV1/uio5Gf+bj/MAEjyh+KrTiSJ0YTq+rLjIYWgzccpZNMcXT8Nhxj2Bcq6gMF5pUf8fo4ip82Vo1nCp/iEfuV3OHU42KaF6DrYPWuImNDt4kACO4r8HT5TAnug69JQd43pWi5+W/lSWzjXbfpCftqr1qofauOxffkGF1ZX1BL2035O6rCYgdVXvY8M8TpgblxfMQLyyt8ouJZeEpU3TypbzeDHq3+sQp9mqLPLE0zH0+uZ8xUWQO/PVtcCVcfAQTYwelaxyLEm74PjBxXpm/NgYFSPpfHnneoKuuyBh+59LJZNTR+VRgInUX0SFNx8V5r47uxUR+shi7GAoSHZNKWmM5rA4q7yrfipLLVG0OqC0Cm0wCHKBDKTzbC/XcTiUfWPO6mso+fZkBOaTAY5D5FRSIxeJEJKiDWhXpQaR/+Q24g9zaEXh1mXjQTt04Tr04je6XKpVha5/Ysb7o2pWkja+v7CZk6j2xoOGXCvQUaEvyNGdYSs8ffxS6Bj/oKe4nZSkg6CfE4TwrkSm+nh5Tq+MkHM4c787AI6yObrM7qVOpjDdlLDEk6ZrRnyx4/wVV0fq5jl8fT1qbUQXb4gUzAUVEtU1ZZD68QcGdYbolcRwUN 9JsBEAf1 aXDZSVMyyajz3uqnduLq2sFoNNRzO+/1EYo6KFYj/UBdrtcSnzsEYZssf8hblCCqNI8RhpbE1bCpJIQ5TaVApaK0DtpJncTtQdG62DIsPLsui6KNJ/1cLxNCNcodme8NFnsiPPLrOVu5auPoaYWpp3+eqnqq2nmo7K1R1qWtVc/lClf60pRuwxtB7AG58MJOjSLc4vm8Yos0vT04MNXTno7Fa1AzS0TnXRg6ZZDHfOCc/51bMsX4ddGwxqGDrN8su6RIDyAqlWUtw4FxhLwnANRKySfz7+twkbIGw X-Bogosity: Ham, tests=bogofilter, spamicity=0.029108, 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 Mon, Dec 23, 2024 at 1:30=E2=80=AFAM Chen Ridong wrote: > > From: Chen Ridong > > The page reclaim isolates a batch of folios from the tail of one of the > LRU lists and works on those folios one by one. For a suitable > swap-backed folio, if the swap device is async, it queues that folio for > writeback. After the page reclaim finishes an entire batch, it puts back > the folios it queued for writeback to the head of the original LRU list. > > In the meantime, the page writeback flushes the queued folios also by > batches. Its batching logic is independent from that of the page reclaim= . > For each of the folios it writes back, the page writeback calls > folio_rotate_reclaimable() which tries to rotate a folio to the tail. > > folio_rotate_reclaimable() only works for a folio after the page reclaim > has put it back. If an async swap device is fast enough, the page > writeback can finish with that folio while the page reclaim is still > working on the rest of the batch containing it. In this case, that folio > will remain at the head and the page reclaim will not retry it before > reaching there. For starters, copying & pasting others' commit messages as your own is plagiarism. You need to quote them. > The commit 359a5e1416ca ("mm: multi-gen LRU: retry folios written back > while isolated") only fixed the issue for mglru. However, this issue > also exists in the traditional active/inactive LRU. You need to prove it with some numbers. > This issue will be > worse if THP is split, which makes the list longer and needs longer time > to finish a batch of folios reclaim. > > This issue should be fixed in the same way for the traditional LRU. > Therefore, the common logic was extracted to the 'find_folios_written_bac= k' > function firstly, which is then reused in the 'shrink_inactive_list' > function. Finally, retry reclaiming those folios that may have missed the > rotation for traditional LRU. > > Link: https://lore.kernel.org/linux-kernel/20241010081802.290893-1-chenri= dong@huaweicloud.com/ > Link: https://lore.kernel.org/linux-kernel/CAGsJ_4zqL8ZHNRZ44o_CC69kE7DBV= XvbZfvmQxMGiFqRxqHQdA@mail.gmail.com/ > Signed-off-by: Chen Ridong > Reviewed-by: Barry Song > --- > > v5->v6: > - fix compile error(implicit declaration of function 'lru_gen_distance') > when CONFIG_LRU_GEN is disable. Did you build-test it this time? I don't think LRU_REFS_FLAGS is defined when CONFIG_LRU_GEN=3Dy. > - rename 'is_retried' to is_retrying suggested by Barry Song. > > v5: https://lore.kernel.org/linux-kernel/CAGsJ_4x3Aj7wieK1FQKQC4Vbz5N+1dE= xs=3DQ70KQt-whS1dMxpw@mail.gmail.com/ > > include/linux/mm_inline.h | 5 ++ > mm/vmscan.c | 108 ++++++++++++++++++++++++-------------- > 2 files changed, 75 insertions(+), 38 deletions(-)