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 E330DE7718D for ; Tue, 24 Dec 2024 19:28:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 33C6A6B0082; Tue, 24 Dec 2024 14:28:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C5806B0083; Tue, 24 Dec 2024 14:28:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13FA86B0085; Tue, 24 Dec 2024 14:28:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E5EE86B0082 for ; Tue, 24 Dec 2024 14:28:43 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6C8D2AE88B for ; Tue, 24 Dec 2024 19:28:43 +0000 (UTC) X-FDA: 82930838172.25.C6D090E Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf08.hostedemail.com (Postfix) with ESMTP id 4DC8A160009 for ; Tue, 24 Dec 2024 19:28:15 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qt1ZwXnC; spf=pass (imf08.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.48 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=1735068484; a=rsa-sha256; cv=none; b=O3WUjE4W1aMiHfrRBq38kYMRUq0yge7HM+1v1f4MrCQcgSLhTkUwXvsPBkaw9bKdBHywGw QdS3owEgbB6CqdKgBymJ3ywaKUcCBpcXTZeZ2sThMKZ/DGjvbQnHCz132iG+JxlJhGGZu6 8KUq6EsejtgGVJPU1ybfWbn6YBQW7K4= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qt1ZwXnC; spf=pass (imf08.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.48 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=1735068484; 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=G7O8FclsOQBlXQnIahAtQ1egSJ3REgEoz6ibTV1KAjE=; b=3liBmHN68s1F91kgS6jMmyWoVG4OH4hbCHEZC30LBohPpo73QXM/lhSkA4S6asVl2svVSs PX5Nriw1FTsTNqDWiNR+yMvrUYy34zD18toJFoYAOOctWVJvuIRehSBcr0pD/2YiEsI9jy jFaFBtv/VIpz1yssFpQi9vxfClzebMA= Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-4aff04f17c7so3599035137.0 for ; Tue, 24 Dec 2024 11:28:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1735068521; x=1735673321; 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=G7O8FclsOQBlXQnIahAtQ1egSJ3REgEoz6ibTV1KAjE=; b=qt1ZwXnCNWY0JtcJ2GZS4pkgFNsqj/7oKpjsK0V8D1TI8jPuZrq2PqsXNQKAHQuFlR BYIO56i0vEIaOxlGSiVZdt1ORlWobaAa1BP3+pxiEa/MFK6VWNuv9BrvdB+oe2RE2bLb mu/UsW71N2CQm+dQWoxLBl4JQfvGWb7XSvwGGFz+9nVMCcm6awtUOQFThp4Avp3S/oA0 3MKLwLQUR/SkzahkQXce8zL/4YUihdzms//EQaa//MU8ZTMfEnrmfd59L29WWuaugaIb R6/APp0PCcWpd6GgW6ji3BK/Yi7n+k8EioZRng+UnCfn2CsVP2qVrwD/ZQs2immjLpBA pekQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735068521; x=1735673321; 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=G7O8FclsOQBlXQnIahAtQ1egSJ3REgEoz6ibTV1KAjE=; b=uSnttq5psSLJjZYVj7z6J0c6/Eox5Tk9sEUxlcXImlRBVlVsh1/9xpCSRbMW+JGHnb henOKMiaJnTnhluLzHyzwJp4oEZzoFFg3gkbJa7Q7fqpKF9nRi60XxreV++YVolu4Jcs u0/1IV1YvfJZvE2gE767b1iyd2SGHOdVVM4TSSyo44/wEte9yObBScsX3dhEyg6DYFPG YWQcqjnnK0OXQa0ZGzic+74a5Q2f+zr5ivbvBUVf8A2Yw5Dh2G0TGmR/3DdfNJIQY17v 9bhGiRPiSZD1CP6vq9J5v3LeueB6pK2ofwqwIsynCNkUzIsr0EDjPd4X5Yo6WRZ/QOrG OxXg== X-Forwarded-Encrypted: i=1; AJvYcCXIM/9bwWKnHAP3HGJz0Zv2DPaiGhVpqv2oKoY4CZd5AfyuJ+38dQDF4a5nxZIhJxJb3OziTmwraA==@kvack.org X-Gm-Message-State: AOJu0Yy5q4ilSNoUy8GPxqOugIPKJvC1uqqy4IHR69Rp2SFMvPpC8qcH y0hsAQhgJLWAmL8byTjoIOyan/xfW3klqJDdgDnmsjFNA86kodigdd47fs3CXZRjxRWpKeA56bU 2lAwyYU1QCBNN9OWkBKnbKKWKA9WR1Ha+9qay X-Gm-Gg: ASbGncss8IwH43qwlb+9nLVQDzBrb886EriiQM+XwHdTGND6KpX0wLcHjGFwDdi4yjO v6uFY/JH21gVi3nSueS9JosCPQ3peIuI4kLbZ0qb8FDoH1lGMpkoCL99bH3g5t+SmQB9yqvA= X-Google-Smtp-Source: AGHT+IFqQawuP7ZwJhoVS3nxTO2xgMHC+w0U3iByxg8HJFgNyx+UFgvGEwseLBDX8nrxJ05AIBrS5cVItNjm++JRsAg= X-Received: by 2002:a67:e884:0:b0:4af:d554:add4 with SMTP id ada2fe7eead31-4b2bbd80fb9mr18276431137.0.1735068520593; Tue, 24 Dec 2024 11:28:40 -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: Yu Zhao Date: Tue, 24 Dec 2024 12:28:03 -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-Queue-Id: 4DC8A160009 X-Stat-Signature: jkrg13rsuhreysm4cocszjzhi3o1estz X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1735068495-225368 X-HE-Meta: U2FsdGVkX1/pD7PGHlzXboZlf9S7H9D2uoFNmkXYV4ig04sZE3EkzgEmXFMXurNL+9DoFm++P1k1dOdkA4LHoDWebiUmQbnIoxi4MTDA6leQIfO85EFBD+vKRz/OTYY27SBlM0hrQS2qvzQANNfeb+HNLp3u60VAVRiVcvOwGirvAHPsK9I+MymH6BS6bJrjLTjsOL8ZJCQQ/UcUj4aGBlU+X9xig6DhuWsWWDQFdN7IcwcaJCmoL0z3ty0mqUOdU9oA0jL+615yieyM2V9KpPI5DdU2vo2M7Nq1up9J+QCUmUMrdNeujyABAyvmp6QZza5LIrgjx1zYz+RI38JN7TB3X8oJKUqJHjXpv5HgeaSHdbzVMmAfwz1wi1Te9Yp0QKjigukn1z8Zsz2gSNuug8XMS6dgKFiV7GwIcHbhFD6TpgSZxH1RvoJPNuQbQAtHXfLZ3RktBhYyMh2XpZ5M1Eu3FMUh3vwZJLsBNMp4YY5cRgWsg2QHdB8sD/SgxK+t3adu6BB8clIafy8eI+dx7q+Is02BM5Ni3GLjSKvHJ1AeThxAZfPXy55z29t3nCccPGFN3sia4Oo2Vx6lz7ysIUUJ3L7v1I4PPmQuhPW2dN5s2OTrcafapjzujWSAPlEeBRSfRDhMtNr7457Zj53QqSJMOTsylywHjufcJGARvCaKS2eU2e0xgy7vtWtDDXagnTG5IdKdcueNckjoRgM8xi2GrJJyXl7IbxsLQCuBh3uQ5Hs5w8dxpR5yxov8dzWH3bAtsQ5k1M/ZviiyCkm18dLANZuUezNvnfROEHfdoIRaCZ/qu+b+fXrEqkiNr6nLfmqD35sKt7+dFWmpvYHMFF0RLwzeQ1FUlA20vMsBOw0S4oQmeD6PMOHoDpFAhHlOOOGRXK48rS5f6v4ogc8iumhhTwBdYYonAr4TJZjmNlUfWEVIud8A51Gjy7s2EoZaJHcjMBUvArLsOqEiYtn 3EBrJMyP wFVJGDgb65szVTQHjtiXnsaZg9PMJacUAR8O/7bfyyhJzyiQLaYy2pORDm4H+NZ7aS8hfQYKP2URZNSy8aN8VGAvQlPabrdM2Tg1D6PNmkGyPfIdoFn0Omk/+wINj1GSgwDquOb17FNx8YMucShR1PPkqpbBR0k8X+GPyqq2HuXyj0aQwh0qFsBKDSrAH2bBcki4aiQM1k6Sij42jMjpmPQQlshyqaVvNiB0l8mtnCtOUnL3t8IeH6XeCGiGbeUwqyCEzdqmUo/H8kknb5PyLlBFMLrvdeGq29cVXqGBVRS5BznX1ioL7s684/zIPl1bFGORd X-Bogosity: Ham, tests=bogofilter, spamicity=0.029445, 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 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 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 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 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. 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 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. 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 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. 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