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 A08FEC433FE for ; Thu, 17 Nov 2022 22:23:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3BF6B6B0071; Thu, 17 Nov 2022 17:23:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 36F4F8E0002; Thu, 17 Nov 2022 17:23:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 237A18E0001; Thu, 17 Nov 2022 17:23:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 131626B0071 for ; Thu, 17 Nov 2022 17:23:20 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id DC60340256 for ; Thu, 17 Nov 2022 22:23:19 +0000 (UTC) X-FDA: 80144361318.05.5B56761 Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by imf15.hostedemail.com (Postfix) with ESMTP id 75D70A0008 for ; Thu, 17 Nov 2022 22:23:19 +0000 (UTC) Received: by mail-vs1-f52.google.com with SMTP id p4so3019027vsa.11 for ; Thu, 17 Nov 2022 14:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FY821bPoJVCLu7rfk693sZXHSCaT036xtgtvYwefewc=; b=nrXnaah14w1gNJlbQj7x3R6fg2QACqgYWYzWr5a/4WXXYTnxsaQDpd4V0WjjKmuU4i 99N7WKk1H6RdYVwnbyYBmQsqMH65/pg7PEWZiksxgr1WEpBxnfTWmLxsXbP9pMOxdBMz FaEl8xGOm9uojH/vYXMG4plJFtNjmGFHqQaTYgkfZFyNDlOqiGa0jS4aDGm6P6t2/L4v C862q3jhyPQq++ViqeE2brXpm9fW8qYhwokeViVoFOEBRr8BBmGH6G72n7fRfbPZcJ5k J2JX754PsWdCSU6tzAdmTAvt9KHNrmeal+bQFRXcaD2BHFfmPd15+xhpjsk3x2ZfAbEi 0fWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=FY821bPoJVCLu7rfk693sZXHSCaT036xtgtvYwefewc=; b=gdbIp5xOAps7SlcKmC6RTKHmqvf3VkMGfK/yikGT1mSn0gWK1CmtYgkNfm+BX/8FZ/ 3eAjYFqiqok3jBs+BMsu6zkLa4V5gGWwXrlklIhLxMxlpW+9TcNOEA3QRcUlfs3ryfon +DDFm1XtRtTSoeWQrLmkyzE4MpFbuF0GBkARpSH30R1hokoRY5YtyYOlz0ilzlVSl2vq 7LEabHmgcLgdrFPR/0UCsAjwBEMnUBXHV3zVKvL9pwaUJleymR6VGG9+lAQmfFnUZNSF M+4MdwexGrGFBFVPWPAojB3zDH3SqmhC+udm6r7s/MBrZNkoW5hACbIovgZO55vRXcJ3 kKpA== X-Gm-Message-State: ANoB5pnreQjYM3/KCQvkEegoxomPAeFhfBPe1dRD/kslucyB/OZKiC+t 6aw42oNYjamzgHEbydfX2+AZywP5ee1vxqEYfdD6gQ== X-Google-Smtp-Source: AA0mqf6/W/LcDy5Qj+/bfLYrJt04/wmLtkK7e5TLrATDWH41pmB3oN4Ih55y3IYo0ao2lC2a3PloKQrF7VEIFaZQI2w= X-Received: by 2002:a67:fe01:0:b0:3af:5ff9:ed51 with SMTP id l1-20020a67fe01000000b003af5ff9ed51mr2814981vsr.46.1668723798563; Thu, 17 Nov 2022 14:23:18 -0800 (PST) MIME-Version: 1.0 References: <20221116013808.3995280-1-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Thu, 17 Nov 2022 15:22:42 -0700 Message-ID: Subject: Re: [PATCH 1/2] mm: multi-gen LRU: retry folios written back while isolated To: Minchan Kim Cc: Andrew Morton , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668723799; a=rsa-sha256; cv=none; b=0Rb9m8MhVHQb6OP6/4MJecZ8buKZIGzfu3RtX14CKjX0UuV1cp9LnUMcMMV6EiLToM4kYN u8Ri3kO9WcrAJh7MEfiv8bisYD2FQzcknToKm0EghBEjMmqkHPXOqf1h18JQ/it+W+FV+n I9PP1lw86prk803aUxl6O9DXWw6Zq9U= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=nrXnaah1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668723799; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FY821bPoJVCLu7rfk693sZXHSCaT036xtgtvYwefewc=; b=Zc0lt5q9wk5qVsF9BKMnA9cF8daR0Dz3LbFZ98n/PlQ8moaSxg81IsI7xc4q+6gc8tJS4G xJrqB1uHajCgb+ImzEe03M3Ai9HR/ATw/ujTGG9eLfdHr6Mo4cGMUj8Ah5X3ZI8r/72t/4 tSNeDdz9zmwGR2Ik8qsgJFMw3fS0BTk= X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 75D70A0008 Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=nrXnaah1; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=yuzhao@google.com X-Stat-Signature: nddx4jdw5uu6kfmnqcaftfkiyjocydmr X-HE-Tag: 1668723799-365250 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Nov 17, 2022 at 12:47 AM Minchan Kim wrote: > > 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? This works for both the active/inactive LRU and MGLRU. But it's not my prefered way because of these two subtle differences: 1. Folios eligible for retry take an unnecessary round trip below -- they are first added to the LRU list and then removed from there for retry. For high speed swap devices, the LRU lock contention is already quite high (>10% in CPU profile under heavy memory pressure). So I'm hoping we can avoid this round trip. 2. The number of retries of a folio on folio_wb_list is unlimited, whereas this patch limits the retry to one. So in theory, we can spin on a bunch of folios that keep failing. The most ideal solution would be to have the one-off retry logic in shrink_folio_list(). But right now, that function is very cluttered. I plan to refactor it (low priority at the moment), and probably after that, we can add a generic retry for both the active/inactive LRU and MGLRU. I'll raise its priority if you strongly prefer this. Please feel free to let me know. Thanks. > 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);