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 18E7BE77188 for ; Tue, 24 Dec 2024 06:45:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C47E6B0082; Tue, 24 Dec 2024 01:45:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 373406B0083; Tue, 24 Dec 2024 01:45:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 261E56B0085; Tue, 24 Dec 2024 01:45:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0A0416B0082 for ; Tue, 24 Dec 2024 01:45:15 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7DB09160643 for ; Tue, 24 Dec 2024 06:45:14 +0000 (UTC) X-FDA: 82928914614.24.960475D Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) by imf03.hostedemail.com (Postfix) with ESMTP id 23DF62000A for ; Tue, 24 Dec 2024 06:44:51 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; spf=pass (imf03.hostedemail.com: domain of chenridong@huaweicloud.com designates 45.249.212.51 as permitted sender) smtp.mailfrom=chenridong@huaweicloud.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735022686; 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; bh=bz63ZoXP+UlggqKx4JyF08YT9egolG/3vSckJyS2yrk=; b=XgAkPmyjM7qqVQkg0f5ipfGh1BwGLCE83aV+CAWlXyyVHLjCMhKp4HLsUMyZ/TNu1oKY/I eZ8omf5S5noQnM/NJYsbYROm2/iaktAQCgMbwDtGB6tn91HN/0zs6cDQAYUpAcaxtqoAum vY1T709vmQ9E+702LvomxNlUt7iGd7Y= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; spf=pass (imf03.hostedemail.com: domain of chenridong@huaweicloud.com designates 45.249.212.51 as permitted sender) smtp.mailfrom=chenridong@huaweicloud.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735022686; a=rsa-sha256; cv=none; b=o/osUtMNAs4/zi7GiekclyBlWdBz8okualZQQ9EC0iuLuNKLc1ZCf5eKrBQcMgd270vHfA P88cRORjGTLGq2M/KEap5Ydh+GgsMV1hJvroQ+PeR13luehOLsr75Uw7K8l4S2mC03RPP7 mUiZyocOvRF9EEkXNFANtpFcxM84v8k= Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4YHQNq1MF8z4f3l26 for ; Tue, 24 Dec 2024 14:44:43 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.75]) by mail.maildlp.com (Postfix) with ESMTP id EA5ED1A0568 for ; Tue, 24 Dec 2024 14:45:03 +0800 (CST) Received: from [10.67.109.79] (unknown [10.67.109.79]) by APP2 (Coremail) with SMTP id Syh0CgDHct9sWGpnuiXFFQ--.48457S2; Tue, 24 Dec 2024 14:45:01 +0800 (CST) Message-ID: <928cf4f0-b914-432b-abd3-36882086f8ae@huaweicloud.com> Date: Tue, 24 Dec 2024 14:45:00 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH -next v6] mm: vmscan: retry folios written back while isolated for traditional LRU To: Yu Zhao , 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 References: <20241223082004.3759152-1-chenridong@huaweicloud.com> Content-Language: en-US From: Chen Ridong In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CM-TRANSID:Syh0CgDHct9sWGpnuiXFFQ--.48457S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWr47Jw47JryruF43XFy7KFg_yoWrXF48pF s3WF4akw1kJr1IkwnF93W3WF1Sk3y8Gr13JryfGryrZw15ZFy09rW0gw1rWFy8Gr1rCFya va13Wr909FyUArJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvK14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j 6r4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcVAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kI c2xKxwCY1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbV WUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF 67kF1VAFwI0_GFv_WrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42 IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF 0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxh VjvjDU0xZFpf9x0JUd-B_UUUUU= X-CM-SenderInfo: hfkh02xlgr0w46kxt4xhlfz01xgou0bp/ X-Rspamd-Server: rspam05 X-Stat-Signature: hx5th9ox8id8kf3rgb1ow3xwru7g4e6w X-Rspamd-Queue-Id: 23DF62000A X-Rspam-User: X-HE-Tag: 1735022691-685192 X-HE-Meta: U2FsdGVkX1+Y5HzjtglHk3HOVgD8VeVO0UIKx7Ljh8XTWaH0QHcQCq1AumzTPvlQ1QXALR8r9NC8LqMoeZz/KD58F6fhZ/dpJd3CVShxx4RT/eAMQYBjwyiiSukikeDpsPVI038oetjVAYEGbXWUtL4e+8mlMoxaIsB8ykDASmV5Yo0voId/TvvfN4nhjGg+0U85S6j8BMkvC2Hl6a7nVplCyD65JSe5syDfDj5qNJYbY9umnqa5mywJlHHd4fxmGyDtV1PODCCMFuMCiWCaRa3C/PXPQPxz4/RW41A9IE+w8Nw+IEHSwmO40edmETIavX2HFFE5K2O/v0cEyPCGDoq/JGRpcagi5IBDFmAF2Y5si7Ks9p+FEEvxCf+DiqSStRqXf0+bo6yJmWA0wTWahOZcch76AGrblvdwKALcfVvXK7RDWJIomReXZSYZh9ze+FOOuY4MDSMc0ot768cjGeHCauT/CSqjZGUBmrqcNlF95y4LywkpYHBKU6t8kzFHY0pWbrwqLUrVhgfMRLN7VtETAFi93tVScLDs3Vt6liEmOBy7DLBcyPZEtutZgaZsQiApmhFzH/OgsA8fcLTmr6M5V/BGB4rPAqjRJ0pKTaFik/Sy0ZvK3IpIKSz9XO+o9FBm4XDC7MF+xJBCBfm4CixgcL0nFt3RpOS/drzKJcLUAUhcFcv9PQ538vxbAxMGY9M+EUYZ76NnfvvvaWJeCh/lBjStbBFJH9CorlAlI1sTB+G+8MeQY2W9DdJ+9DvFOQsQBzChM/aoF2SAlq4UjEY5WT0x5EuLsuPTQbJh4/ZSPXa5EsINepsjdhbDJOB5GDxkaWpTdv5n5wSHY525vU1T8XVZauK/TkNuzDRkf55X+UmOOfLzhocBxdTuvpa7yh5is804w3uEX2w43ss09rIL7tXSF4EQ7HL6Ba+keLjSLwuH+pu6uqoaJHHiTLEsgRu3wkY+K5++IwY0uU1 rvgJ0PE0 BADYQCGlEGNV8K/pNYSXUqsrT+7MAe67kdhlRDNloI8d4k0kgE638Sl2W58z3gSfei1K1G5Cxe5xJ8UdsCOc/gRC7Yuiy3YqTHUavvwZ7wqGeP5wWxmZ77a3ePbxsfqNHuW72wxIkT1Bo2FUxfvn8gwAnrVswwASlTqEIiikbLuttmJq7fDus1hTCbnuRM8umrrpScBJZ1BLKHorq1ozsdwrkMkCiebg6QOW4TtpChcooQRb7itJGe9t3pHR3EcpB1863eHZa+GaSHruGhjnwAYuYKA== 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: On 2024/12/24 12:19, Yu Zhao wrote: > On Mon, Dec 23, 2024 at 1:30 AM 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. 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 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 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_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-chenridong@huaweicloud.com/ >> Link: https://lore.kernel.org/linux-kernel/CAGsJ_4zqL8ZHNRZ44o_CC69kE7DBVXvbZfvmQxMGiFqRxqHQdA@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=y. > Yes, I tested. I didn't test when CONFIG_LRU_GEN=n in patch v5. I tested with CONFIG_LRU_GEN=n and CONFIG_LRU_GEN=y 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=Q70KQt-whS1dMxpw@mail.gmail.com/ >> >> include/linux/mm_inline.h | 5 ++ >> mm/vmscan.c | 108 ++++++++++++++++++++++++-------------- >> 2 files changed, 75 insertions(+), 38 deletions(-)