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 87B11E77188 for ; Tue, 24 Dec 2024 19:34:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 00A4A6B0082; Tue, 24 Dec 2024 14:34:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EFC5A6B0083; Tue, 24 Dec 2024 14:34:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D9CDB6B0085; Tue, 24 Dec 2024 14:34:03 -0500 (EST) 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 BA3106B0082 for ; Tue, 24 Dec 2024 14:34:03 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6A352C01A0 for ; Tue, 24 Dec 2024 19:34:03 +0000 (UTC) X-FDA: 82930852368.16.45D5E87 Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) by imf22.hostedemail.com (Postfix) with ESMTP id 6AB2BC000A for ; Tue, 24 Dec 2024 19:33:20 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dAYyCsXt; spf=pass (imf22.hostedemail.com: domain of yuzhao@google.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735068814; 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=Xxk9TLL8fp61b4dvE/dM8bu+zsiAsbIPJyL/AjC38Vw=; b=DNPvBjDvm5D9oQ8gavSnR04PJozivLsXhhVSq+6A+YXYEAamb0U+w5VnTZcb1qRnmtczh1 b+lUJX0B+ANiPb0LFRsJmKI744XJJ1NorcPvpOm9tMHgPQHZrtE8g+CcljPSOiqn5s4bXp O59XlRpV4ng1EKya7IsNylhOzKb9cDQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dAYyCsXt; spf=pass (imf22.hostedemail.com: domain of yuzhao@google.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735068814; a=rsa-sha256; cv=none; b=ZX9hgeqYa8wBDeKStQJLCe9l38o2d2fi2l4eKLXvjgdNnIXNm8FpGfXaAA+DQaDEKh83SB sDTHzrR2yF/xuDno1B32YleM0XaxTZwYEMbjy5sniaxmwVLMnrDC+AceyF6QZcklb2XwBT VssoXcP2gAwqdXRUl8SG4qBA47uvejY= Received: by mail-ua1-f47.google.com with SMTP id a1e0cc1a2514c-85c5316f15cso1326253241.1 for ; Tue, 24 Dec 2024 11:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1735068840; x=1735673640; 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=Xxk9TLL8fp61b4dvE/dM8bu+zsiAsbIPJyL/AjC38Vw=; b=dAYyCsXtKvQdcJhkNLx09dKZi0dbjK9e7BesgdRwbGFhu+9P+hRpeuMe0Yo50boXrQ EXHYcte4+/DA68S9QfHWJb2uBwS1OVICtRM0fVmXAWkBbTMzwBJyo6gv7OONUGn6bZvl rOazGzzmSn8mbqpyF3DNUuJ//ie5nlYLr3vqvhGhaJuv/cSFW8DUUr7kAAr6uJreC7l8 XleccVyGtIKlVAXVaXSCEvsaEY+3t+MvKGbmkAZ+FM5ZSKDq74/dONjCM3bWwWyHHOTa ttGAnpQ4E3tcuMN+CC6nG+oJCe3Hql+don/4Sf/cFrA+bjcwnRgLbMvW6rbFY8yXm5k9 0s0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735068840; x=1735673640; 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=Xxk9TLL8fp61b4dvE/dM8bu+zsiAsbIPJyL/AjC38Vw=; b=dK+vyqYZ6EnngrYU63dRwX/sEhNlTJ3zilp72yeW8hHEHsfzN+YY1WrvJpDNFMidto jdbRkwfN0k8WUFxxlFeQw4H3TBB/de1XPIpgB8MxCp4zS9wbmKmcbnFmcKVAidW0dojI dvwM5jo+2H3emt83fERql1kPUWy03KhHyY7kAHqaRrbVx9MytMSTdtQTN488ocTnSxiT 0h2hvNP10nJfmS9JqdQzogfRi3KnFxyK/W9LZV1hyUzfO0rlQeI4wH/bRGDqIUP24N8L rjd2exoxVFMwCxKo6rmlzqIWfX4m674eFjp9vdOYuywLqVSCBh33KhfTSDQIt7SMDoj+ 6PHA== X-Forwarded-Encrypted: i=1; AJvYcCVC7JE5elltblwlhBmzqft9TRbvzE44vexxnVOjqBsL9CL9UYYq9mipDtP/jViWZVxC6uEojuEfYg==@kvack.org X-Gm-Message-State: AOJu0Yz4HgzPjoPD7AOknDbWhvr7N0qDTqd3eLcntBdvAdPlYw8uLvsp N2Bm6qq079Thn0UdRjPSHHIGGOqOT7NLUwok3Dg3d6EcYpSuUfqGCk6qLHwEJWXaUkgipeo9zBm a4NnY6mhfGsAc2mxZfSs7bb+ZjeQ3u631rAAg X-Gm-Gg: ASbGncvO/hmGP/Yf6n/anfEPyiIN+gHmNiHW4daHbYFTHtMBSbqP20nTSNUPz+Bp0XQ dDZUHoML2JeNYeXfN73Z+O4BY6T2C8Scseawx8zF9zBVeDJJr5wuTTaeSF8+g86yD+OcWAWc= X-Google-Smtp-Source: AGHT+IEiadnJG2ja/eL/JeAlI7tApFxWnLumlIxd2N6ifJF5J5EuHecf35nmHB9vE1iUWH+y51cPtBGwgoAeykkkSEQ= X-Received: by 2002:a05:6102:26c8:b0:4b2:5d63:ff72 with SMTP id ada2fe7eead31-4b2cc3862a6mr18136830137.13.1735068840460; Tue, 24 Dec 2024 11:34:00 -0800 (PST) MIME-Version: 1.0 References: <20241223082004.3759152-1-chenridong@huaweicloud.com> <928cf4f0-b914-432b-abd3-36882086f8ae@huaweicloud.com> In-Reply-To: From: Yu Zhao Date: Tue, 24 Dec 2024 12:33:23 -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, wangweiyang2@huawei.com, xieym_ict@hotmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Stat-Signature: zu3jgf9edxtehjtbco9d3zghqq593cdc X-Rspamd-Queue-Id: 6AB2BC000A X-Rspam-User: X-HE-Tag: 1735068800-637945 X-HE-Meta: U2FsdGVkX19PDiypbcLpUu3EcUpnpfkWiXLD83KLSgdSHJCbOkLdfHkpd8gnZEOhgkehH+Ec1ivwWCFC4l4bDXzMZlv6buW1bHq3yI2zTUAUi46a19vT4EvTNFngN1A4VkCpKtOe2orbG5aWe1GV5lCruFpOFzuolZFhB0//RAV8RXOR75IrJBDQuwwnzNVY0Lyji5HrIjnoEd6uDi7RTyBK9HLEcmNj1tegcR7iM5ZFrZRnOfC/6ayqrQ5Xf3986mLxl6p9y+Rj+AP3c+tfhlzjI0qKtidY6g0dmkBhrHmfxhyQjaYKnhjnv/xXvSy/MwxesL+gQDsK6vBMgzplqfPrdMpABxngz2YDZ6DUXbqCHoPz9UlgVXpy453aNiDdUor/ejsGBcd31lQ4x7IgXd/V5dOZElyUbSs9XISRRHgW2xIMZVS0heqkr1DeDExBY7+2Yr8J4O6pQRCv0HYRfmXHIAbsbeVYM5j/mmOsm1XEa8cKUPzP9jETlwg4nSucndZwGFsXSt6lj9d57aAyS/HI+ODPYlDm6ju5WKuTruxHUJIdXhyNiIDP+ia12h9tXDAHtB0YwPRVrJO/GUJeGHF4sYbAbwcfuleB12eu1kkiKNVEvCtMqMQj588P3OYKTtSGTt/YkaH8sCrrwe/AIM5LzI33eGvSLLq+C+50MZ0IYuAh06zEYEz3wuHSvTc6VY22Zn1D8FfLYiYpP0YExSals1dllAIInisRKkFwS99KP1KdJUE/YNm0qDljlBaTgxSvFo3JjhkQ1GKJr/jXPBkoLolyu9N4/Wkg+CSEDZLFRwnKJpnlWD3VODZinqYi+laJwbPPuuUc3FLQnhaAEtNXhTj60X2SaQZ3OuRLC3t1THyLtkWDRekKnwQsZCE1DGTwBYYgc7Drjkg87FMe3WRD1ZE9c8o68qA+I/94IRbkitcVGXMIGBxN2kd2TSvetGlcyjy0+LSMJ0H+zHn 3y4hui70 jgHqwdkrG5bB9nL2a9ZHnf170cvh6F3zrU2+va2OZCU17OpOTlh55jjMqAUT1+qVbi9paxlOj7BFt4b9h43nbv5BFylQEB/YN5TXvISFAMh+jelge5U/UQauHREM8hiYWSEeLvQXYxH9kkF0GARcNZC8sjw3GyiDtcZRHHO0Gt8h8XbZHZaTi8VLoZytgoj5oWcFpV8aTfUSidyYi+Buxs5McWZYdKJi1BNuKrfvqB4vkT3H7RDxOo/h/VI9d09MHgt5pr1k8ZvPY4wN1PqPgaa8mSe9TrR+7/6mVZEHR5R0QVN5095kwC3KIyGZM1ki19CW0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.050621, 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 Tue, Dec 24, 2024 at 12:28=E2=80=AFPM Yu Zhao wrote: > > On Mon, Dec 23, 2024 at 11:45=E2=80=AFPM Chen Ridong wrote: > > > > > > > > On 2024/12/24 12:19, Yu Zhao wrote: > > > 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 l= ist. > > >> > > >> In the meantime, the page writeback flushes the queued folios also b= y > > >> batches. Its batching logic is independent from that of the page re= claim. > > >> 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 rec= laim > > >> 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 befor= e > > >> reaching there. > > > > > > For starters, copying & pasting others' commit messages as your own i= s > > > plagiarism. You need to quote them. > > > > Hi, Yu, Thank you for reminding me, I did not mean any plagiarism. I am > > a beginner, and I do not know much about that. > > I didn't think you were intentional but please also understand this is > a very basic rule that applies everywhere, not just this case. > > > I wrote the message in my v1 and v2 to describe what issue I was fixing= , > > which is wordy. What you wrote is much clearer in the commit > > 359a5e1416ca, so I pasted it. I am sorry. Should resend a new patch to > > modify the message? > > > > I have sent all patch versions to you, and I don't know whether you hav= e > > noticed. How I wish you could point it out at the first I pasted it, so > > I wouldn't have made this mistake again and again. > > Here is an example of how I quoted from another commit message: > https://lore.kernel.org/20241107202033.2721681-5-yuzhao@google.com/ > > > >> The commit 359a5e1416ca ("mm: multi-gen LRU: retry folios written ba= ck > > >> 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. > > > > Do you mean I should prove it with some info in my message? Actually, I > > encountered this in the traditional active/inactive LRU, I did not know > > you had fixed for mglru until Barry told me. I offered how to reproduce > > this with Link. > > Yes, the first link does describe how to repro, but you also need to > show the results after your patch, i.e., the improvements from the > change being reviewed. > > > >> 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_writte= n_back' > > >> function firstly, which is then reused in the 'shrink_inactive_list' > > >> function. Finally, retry reclaiming those folios that may have misse= d the > > >> rotation for traditional LRU. > > >> > > >> Link: https://lore.kernel.org/linux-kernel/20241010081802.290893-1-c= henridong@huaweicloud.com/ > > >> Link: https://lore.kernel.org/linux-kernel/CAGsJ_4zqL8ZHNRZ44o_CC69k= E7DBVXvbZfvmQxMGiFqRxqHQdA@mail.gmail.com/ > > >> Signed-off-by: Chen Ridong > > >> Reviewed-by: Barry Song > > >> --- > > >> > > >> v5->v6: > > >> - fix compile error(implicit declaration of function 'lru_gen_dista= nce') > > >> 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. > > > > > > > Yes, I tested. I didn't test when CONFIG_LRU_GEN=3Dn in patch v5. > > I tested with CONFIG_LRU_GEN=3Dn and CONFIG_LRU_GEN=3Dy in patch v6. I = am > > using the next. > > I see. I would base my patches on mm-unstable instead -next, i.e., > git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable > > >> - rename 'is_retried' to is_retrying suggested by Barry Song. Also there is a subtle difference here: `skip_retry` implies "skip retry after it has retried N times", and currently N=3D1 for MGLRU. The change you made implies "only retry once", i.e., you ruled out the later possibility for N=3D0 or 2, etc.