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 33D35C4332F for ; Thu, 17 Nov 2022 07:47:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 785636B0072; Thu, 17 Nov 2022 02:47:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 70E166B0073; Thu, 17 Nov 2022 02:47:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 589CE6B0074; Thu, 17 Nov 2022 02:47:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 44E066B0072 for ; Thu, 17 Nov 2022 02:47:00 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1D8A51A082E for ; Thu, 17 Nov 2022 07:47:00 +0000 (UTC) X-FDA: 80142153000.14.628B53A Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf20.hostedemail.com (Postfix) with ESMTP id A28001C0009 for ; Thu, 17 Nov 2022 07:46:59 +0000 (UTC) Received: by mail-pl1-f171.google.com with SMTP id b21so863492plc.9 for ; Wed, 16 Nov 2022 23:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=Y6xiQj3Snw2925U4fvhfrjNHHEHb0n1jmEIKfobWlb4=; b=XwS/csrFHKQrJz/CyWykYx7kjufcCjuyLIL5xCpHkoGq5kjeoX0ruPdbqoabJImuqj fKKPzSJTg155EkRkbDUNADSX7VsbEoMz9Phgpjs0uUOQI/2bKtJLo0xTFqS6Rfx2FfsB z8NL0Xs6Iwk9fe1Dq9+kTtPuXUGNRIaikfrz5QSOoUaxwX81b1T97zjoHJuJ+Rq2oMLW CK8Q4SoTAIwSbOmB7YTlO6KGfVXjrvgZ+YyQdJjL7iRZcz+m5W07msZL6eA+64DupPRw qjmaiZouQBxBAtBZpXkeBURyY6E6IT8ERRcbRNKIt8LGqsdpJq8Q5hicxCXarnP7N1rv olIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Y6xiQj3Snw2925U4fvhfrjNHHEHb0n1jmEIKfobWlb4=; b=MjQ83douZ2jce1uRkqm/ayRcBJm0Lyj10QujmGj50svkA4T4Kv1YqQc/QJz7w3Tad5 bX4tRY1DPSw2rtdga8UE8KKFOWAA4lrykM96a0Uzo7mHU7kCc2cSd4OngOpx6XxDe4Ar JE3y9mwxHdve/vogcdN4JcabyVP43DBwsSjzd4svSu284DcaiRxjIPCktZ4GZB3NjEYf wDRukio4qRFwojBL2AXcY66vKYD7xZkAVpTrKbgJ9VTdN2vLNGk7h+4+7sRejl2e4Uky dG3ma4ze2OwFzqsbgYUuPJproPvilIxqiv4heClDSvN5HOjl8oxebBldB1PVGu8AHRtw a5mA== X-Gm-Message-State: ANoB5pmFhn1UAFu97vaku+Ghw392r05Lq2vk73u/U/2wFG6RsuE24OCK mP+Y6MunLTcPz/dnGVsgV4g= X-Google-Smtp-Source: AA0mqf5Hm/NSlFOEFPg6cLRc7bl20y7xOUWjkn5wQViJI7RoV9uVdg8Qy4CdQx60LQweR4nYqfsWrw== X-Received: by 2002:a17:90a:b011:b0:20a:97e2:5373 with SMTP id x17-20020a17090ab01100b0020a97e25373mr1530553pjq.200.1668671218326; Wed, 16 Nov 2022 23:46:58 -0800 (PST) Received: from google.com ([2620:15c:211:201:3439:fe53:7a5f:f579]) by smtp.gmail.com with ESMTPSA id nh9-20020a17090b364900b00212d9a06edcsm2868989pjb.42.2022.11.16.23.46.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Nov 2022 23:46:57 -0800 (PST) Date: Wed, 16 Nov 2022 23:46:56 -0800 From: Minchan Kim To: Yu Zhao Cc: Andrew Morton , linux-mm@kvack.org Subject: Re: [PATCH 1/2] mm: multi-gen LRU: retry folios written back while isolated Message-ID: References: <20221116013808.3995280-1-yuzhao@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221116013808.3995280-1-yuzhao@google.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668671219; a=rsa-sha256; cv=none; b=y/EZU3Ql2J4Re18j+4Q0r3zNH9atpnQYpuaQnjPFEfGKP+LN4cN9YclaYhhv6fy74C5MBc CPS+6gDU0waH5m/eojM4WvERr7RKjGvn5w+IoioG2vnOpKur9Nz0iCzXRw7EqzQJh4f9iG kHWpqcr5FxWQUJN47l3LXMdTT6bIE7M= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="XwS/csrF"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf20.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668671219; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Y6xiQj3Snw2925U4fvhfrjNHHEHb0n1jmEIKfobWlb4=; b=3vwSfE5erOlXe0MzB9bIVIM39lH6sRrhBA4vMoBdKR+3tK98w1WO3N5N/rV+9Oqwu8MPDX VzhGzDWfXY6Ig2fttzjhECUNozxZHC3odAmog/HIqv1Oyg5CinL5A0PTMjhn0sKuL16MHf VVpA6kBCkBM9OFTPJm8gjCDENgbJbl0= X-Rspamd-Queue-Id: A28001C0009 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="XwS/csrF"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf20.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: yuso4gz849kiiydar4p47bq3ts7kqxrz X-HE-Tag: 1668671219-770585 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: On Tue, Nov 15, 2022 at 06:38:07PM -0700, Yu Zhao wrote: > 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. > > This patch adds a retry to evict_folios(). After evict_folios() has > finished an entire batch and before it puts back folios it cannot free > immediately, it retries those that may have missed the rotation. Can we make something like this? shrink_folio_list(struct list_head *folio_list, struct list_head *folio_wb_list, ) pageout goto keep .. .. keep: if (folio_test_writeback(folio) && folio_test_reclaim(folio)) list_add(&folio->lru, &ret_writeback_folio); move_folios_to_lru(&folio_list, &folio_wb_list); struct folio *wb_folio = lru_to_folio(folio_wb_list); /* * If writeback is already done, move the page into tail. * Otherwise, put the page into head and folio_rotate_reclaimable * will move it to the tail when the writeback is done */ if (!folio_test_writeback(wb_folio)) && folio_test_reclaim(wb_folio)) lruvec_add_folio_tail(lruvec, folio);