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 70627E77188 for ; Tue, 24 Dec 2024 10:01:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ADE246B0082; Tue, 24 Dec 2024 05:01:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A8E6A6B0083; Tue, 24 Dec 2024 05:01:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9561D6B0085; Tue, 24 Dec 2024 05:01:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 76C846B0082 for ; Tue, 24 Dec 2024 05:01:46 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DBA97C16EF for ; Tue, 24 Dec 2024 10:01:45 +0000 (UTC) X-FDA: 82929410634.29.5DEDC07 Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf20.hostedemail.com (Postfix) with ESMTP id 7FD6E1C0003 for ; Tue, 24 Dec 2024 10:01:03 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SsvT5kfI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735034467; a=rsa-sha256; cv=none; b=e+Fb+wq9QekXw7P8JgrPvbcuVjwG3Zx3oA5TUp3C5T/8GappogHQK3e7RiUGBXVT3iU0Yu 8noEFrR/7nCmzjZwmNrKu3sEoDRqgNns4K2SBa3FPRAm0ne/wN1Go3EXKSrCEZFh+Jlwue VU9M5Lphm1mAwRGxUY5h8knIdfbaq+Y= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SsvT5kfI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 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=1735034467; 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=sb0C3ExexY67Yzyp+sROa8ut5LlrwlvqgZLQMp5bw0c=; b=OzQxme0xwhN/4t7zFHVTCd0vtvjpZeYbjw+i9M1P+kbqdxymWT1eMwCtKvo9IGaEV8GSUw fiACI7roZkwGFwYmUCG+IWLu+VlfHcsvLsG7e7cNiiPazRtQBUMIatJC8CPjLaFzyBx3zV jYqUrJT1JixMDcZ9LwuwCLoqAvrsdQI= Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-5187f0b893dso1590926e0c.3 for ; Tue, 24 Dec 2024 02:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735034503; x=1735639303; 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=sb0C3ExexY67Yzyp+sROa8ut5LlrwlvqgZLQMp5bw0c=; b=SsvT5kfIaIh7s9xwq7kqkmRtMQGdKKSDxNx3EihkBP6N0VI0Z06reYV1l1RCcrXnzP EIcbP+uRevaea8VkxqoxSRPVdL3zr5u4E98Vtkwe7yH4JYd9hADKwMngJesKdLOO26oP 4Ec48vxZZBFW/0lAajXPpllhtRPibNkcBAOqt8znb1iUfFyCanRoCrcpdZO0OwaTibIW 3R1e+AFvxFsUseSa6O7DfAZmz4hVWjx0sIPCGrF9G5QuRNqs6xm68HOrgzsxl6Ud6HmS VeQgUM/2V3u3o2XKPz8ScpAJnkm8VHL+gMXZVSjvNyI8OiBMcvPpxmCKpBp3v/7A0suV z+7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735034503; x=1735639303; 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=sb0C3ExexY67Yzyp+sROa8ut5LlrwlvqgZLQMp5bw0c=; b=EbJHXzO7RaAn7E+osy8IzL5xi4aVjs9/vIqreafqtUFg8b3D4e3pwLO/xSnSl76Mvh 7zzPG/fK23ZiZSUULvN1E6jirBVuIJVGGQspyF8xxtwcbC6SfU3QeCGDZBf9hACAOvgV BISruqm6IJttOihRvCTDSvV8yTcNHbUOtXyrzPWiCGtpTEWq7BvAwGQWptcDc8WJgjpL TjJnTrLmRMiVCu5H+Gf9ZuuMTZOPKNexxOEJcOKRLIwrJ1lyRgF6NEiszFPs5CZQroHf uYPJF6FB6xbROOvQrpBCm68J06iXzjAq2Fo1irNCb4AhyPmR4vhdbPqDr5Ypi2G2EYXr 3TIg== X-Forwarded-Encrypted: i=1; AJvYcCXg5e49D3shi7MK92WXCVarP5tYpY1AJTmha8wysrrIJq0S+020zH3w1IrtvsbUOK3Et5fyYGgIHQ==@kvack.org X-Gm-Message-State: AOJu0Ywhhst5xRfSUKhemV4oaWmKPcTbLnVg/ajcz0Ft2rY088W22ijS xR6fGR55rfS5h0+4uIUkkzZ2ZfI7qbmo1ajfzvWczfRZtVn/TB06Zoq2eysckNG8DjQLxgaLxCK RTe9ypkRtTd3FDFmDu79v5kDYhPg= X-Gm-Gg: ASbGncu0PH5UtGnOGDxnNgQgjjHgJqPDIGH7VwrHbvcxTLcqo6uz55WD0dAYZbdHXf6 QZd0kJl+f5BwqtLRRN3kHVYLworZgH383UzBY970aPodSYMuaOqVbaTIs2oNNED68qS814iY= X-Google-Smtp-Source: AGHT+IGbeLNNz710B2KRSpZKSZa1j+XEFOMVTXIeyMx4/eMqrtbOcgYE2VStmYjS/IohfsAcT8lcjUUDb+kvj9dIwsU= X-Received: by 2002:a05:6122:1816:b0:517:4fb0:749c with SMTP id 71dfb90a1353d-51b75c42ddbmr13936668e0c.3.1735034503075; Tue, 24 Dec 2024 02:01:43 -0800 (PST) MIME-Version: 1.0 References: <20241223082004.3759152-1-chenridong@huaweicloud.com> <928cf4f0-b914-432b-abd3-36882086f8ae@huaweicloud.com> In-Reply-To: <928cf4f0-b914-432b-abd3-36882086f8ae@huaweicloud.com> From: Barry Song <21cnbao@gmail.com> Date: Tue, 24 Dec 2024 23:01:32 +1300 Message-ID: Subject: Re: [PATCH -next v6] mm: vmscan: retry folios written back while isolated for traditional LRU To: Chen Ridong Cc: Yu Zhao , akpm@linux-foundation.org, mhocko@suse.com, hannes@cmpxchg.org, yosryahmed@google.com, david@redhat.com, willy@infradead.org, ryan.roberts@arm.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: rspam04 X-Rspamd-Queue-Id: 7FD6E1C0003 X-Stat-Signature: 3chp1h95up7tonuxptz4jea3coat6bgx X-Rspam-User: X-HE-Tag: 1735034463-773871 X-HE-Meta: U2FsdGVkX1+LGtqap8mJZm1NWJWYCSe9K6/VDeFXOGg0Z8Ml9ZJH73kDCxF0HblNhrK8Heuo37ghZ2PlPwgwh4Y2eAPBBLdGGq+8U+pCg+jWI4V55aiAZGCejw/6wGKPQ5RHRbTvijx9pLdiXrKW1sPxmQjTWOuUez9Udbs/Zqy6Joyim3BdAO2B8ebG/vvKiqebE5MlRiJCwnmZopZNsJus6rhFrZlYFMxprcAxPgYfbtqCMV3zIG7xBPTYO9FF6OLr3biBA1J1+Ic4ahUILFw219rlnk1TQI00PMEAQfT7brGXrxaLsa4N0L/0+jjOAVSDKOEH7PDVbfYLwpHaDz3IrdDpVzAzzpczAO7i5CiyT9gL1hRbZofU7XGnE8S2btrG5XYC3D7/tWcbiWvSQLTf14qI1QUxtPZiH9eW1MsX1Kehi+yd6WvsVO08lzjcx1eZ40nsqdwjxWcxVbEVlbDfnQHHD+BeeJmbC6bwz1kDBbVIwnynDInB5h1+iiD39lAsBfXIDE5yVnbJbuSo++y60sHMbG4u5/XCu0uFKBH1kcO4NiDKLdcTY1JlEx83aP/71iJ6/rxxLWPWItLmQCCbkf38sp/gAJZF9HvtNjoZp3tpxFU7o/eYRcOS/M8UFh0xl5IusOcKYe0SZQ+wfbi7ghcQ5h084plrK6S7nY5zT2Oh3/rIwPm3V5pcfK2SYVtaO7NCr7wppLUcZgVcFpwh5VQqgW9gEULkZsYWFcZ33eIj9Hd3cwShzHelWmfTReMV/m4mOfl63cdl3ml101LGI2aAHUCN0Ug8RmotZA47Oi6V77D1CK6bCUY+hLVNCktSv7V3f/DJP0a+Z/fP2uXh3+JQdgbJga7F3XIw52OdkpLiew3nmjxHaQgMQgsQhGBlqMuJWFrHPYz1AcuXZ8Iy1kY2+CpqIz8GmPWg8sTejnJjhbPZ65OWzQBZp0ipK/RXsFg3/R9KCgL7LZ+ MrtgL4lN Cp1pmNMTSQI8VNMJEL+YsYxgwnKdHkjHP2yf+9uYDmyB0QYPobQ2aIFZn3d43knEoewb9OgUbCaUBKO35zodqpPe400VeWWh/2I6gNSKpsLT6ukXBKyuTyDiqhFqfv2MlGv/jPDEXRr3Omwy/Nm2o9ngLdx/aEPWQWYPAOtvml3fuyXOAZxUduDmyZzmpwA7dBT6j9EBcnHrybJOAE6tcGEMfEd2KstA5ZEJ8ZlIAULTwDdNSwhuRo9aZj5oiznhmIVbetQaiqxWKQrAI6CFZCse9plJpviDp09+BpgcvTGKxV1N8Ocn3c59kT95ZbfYGRu7zDHn2Jr3pVqyFul7Z9+c01IKCqGxN5/V3uXW1VwovT8u+gVYV5LSAhNINQFFLjcctZuQrLL5rh4W9nj0TK0NSdID4qpJVrggi X-Bogosity: Ham, tests=bogofilter, spamicity=0.199314, 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 7: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 th= e > >> 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 f= or > >> writeback. After the page reclaim finishes an entire batch, it puts b= ack > >> the folios it queued for writeback to the head of the original LRU lis= t. > >> > >> In the meantime, the page writeback flushes the queued folios also by > >> batches. Its batching logic is independent from that of the page recl= aim. > >> 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 recla= im > >> 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 fo= lio > >> 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. > > 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 don't think Ridong's intention was plagiarism. It seems this was likely a= n oversight in mentioning that these commit messages are quoted from Yu's commit addressing the same issue in mglru. It was also my carelessness for not reminding Ridong to include something like "quoted from Yu's commit..." and adding quotation marks. > > 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 have > 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. > > >> 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. > > 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. > > >> This issue will be > >> worse if THP is split, which makes the list longer and needs longer ti= me > >> 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_= back' > >> 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-che= nridong@huaweicloud.com/ > >> Link: https://lore.kernel.org/linux-kernel/CAGsJ_4zqL8ZHNRZ44o_CC69kE7= DBVXvbZfvmQxMGiFqRxqHQdA@mail.gmail.com/ > >> Signed-off-by: Chen Ridong > >> Reviewed-by: Barry Song > >> --- > >> > >> v5->v6: > >> - fix compile error(implicit declaration of function 'lru_gen_distanc= e') > >> 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. > > Best regards, > Ridong > > > > > > >> - rename 'is_retried' to is_retrying suggested by Barry Song. > >> > >> v5: https://lore.kernel.org/linux-kernel/CAGsJ_4x3Aj7wieK1FQKQC4Vbz5N+= 1dExs=3DQ70KQt-whS1dMxpw@mail.gmail.com/ > >> > >> include/linux/mm_inline.h | 5 ++ > >> mm/vmscan.c | 108 ++++++++++++++++++++++++-------------= - > >> 2 files changed, 75 insertions(+), 38 deletions(-) > Thanks Barry