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 5FEF1C48BC4 for ; Wed, 14 Feb 2024 09:55:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B61618D000E; Wed, 14 Feb 2024 04:55:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B11468D0001; Wed, 14 Feb 2024 04:55:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A00238D000E; Wed, 14 Feb 2024 04:55:07 -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 8C80C8D0001 for ; Wed, 14 Feb 2024 04:55:07 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D4055A0CC9 for ; Wed, 14 Feb 2024 09:55:06 +0000 (UTC) X-FDA: 81789951012.04.B91776A Received: from out-175.mta0.migadu.com (out-175.mta0.migadu.com [91.218.175.175]) by imf02.hostedemail.com (Postfix) with ESMTP id DB52F80013 for ; Wed, 14 Feb 2024 09:55:04 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="B8139V/X"; spf=pass (imf02.hostedemail.com: domain of chengming.zhou@linux.dev designates 91.218.175.175 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707904505; 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=tgL1/XXlrbSgs6oQPri9u0QQwKNJD0t24q83vYKA7Xo=; b=W4rrboXtMrJUJBJdhAlEuL41sj60BJicGkvjlsxcEmRL+EWLfz1HDuWOl/XqHy68EnDgcG 8yvDy/RC32cBTxXjiUGklEmddxDjRPXZKfT+T42U03HOjMcYBSa4T+3ZnWtxfCpUchJCJN q2+aKBoOh38xIcLBY1UQ8c5zM54MFyA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707904505; a=rsa-sha256; cv=none; b=ENmA7D8aiXL1LY7OZQG5s9WgUdCVSI8VWLP74zLWf4etIwR1wMo0ILoM96aOq1Et81KV3b fbKP4AbgfkbURqHPSNxnJJp/ps2bDV7Ln2P+9SrbCrWS3ph4TRlxzYTQqMAwzt39pUPihb 796/TxOD2s1dqMR3vKJ+o9sfAUG5A/Q= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="B8139V/X"; spf=pass (imf02.hostedemail.com: domain of chengming.zhou@linux.dev designates 91.218.175.175 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Message-ID: <3f7490bb-a36e-46aa-b070-7e6e92853073@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1707904502; h=from:from: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=tgL1/XXlrbSgs6oQPri9u0QQwKNJD0t24q83vYKA7Xo=; b=B8139V/Xt2OCwMY0pSK1lirWCQTX+9UV0GAYObxQilxRfcqDKg29ub3uUsc/KzGT7HyTQZ 5GBmGQiuzytZV4a6tTNsqPDbvEvkSRQfeZaln09K9vfIadoAW24MdyRul4czSF/JsqbyR5 MO9HjSkASomCs11AaZbUxvLcii9gXJg= Date: Wed, 14 Feb 2024 17:54:56 +0800 MIME-Version: 1.0 Subject: Re: [PATCH RFC 1/1] mm/swap: queue reclaimable folio to local rotate batch when !folio_test_lru() Content-Language: en-US To: Yosry Ahmed Cc: willy@infradead.org, hannes@cmpxchg.org, nphamcs@gmail.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Chengming Zhou References: <20240209115950.3885183-1-chengming.zhou@linux.dev> <20240209115950.3885183-2-chengming.zhou@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: DB52F80013 X-Rspam-User: X-Stat-Signature: aiz3yimt3akea6pacneaixhrbxoxhc3z X-Rspamd-Server: rspam03 X-HE-Tag: 1707904504-306227 X-HE-Meta: U2FsdGVkX1/uZWm29CtzJ5Lhc94pGA0rKGZSpejU4Gt7ILSI0NNZkEsfs246vVXmSwf713JvwbutxbKXhGBmSSIqrL+cFrsCY+yOrYxDOHefz2gDVBnZ8i/ZGQSvyzWUaGKdxY3StpGyhi5zLx8Z4dCVaVQtBmclGDEENehiHBcfhW8bAsSupoZPNViKitPAtMvOhnBI68u6kaRI3SlXcyr4hGsJziDxk3YwsGfJpx4WkKKuhTdDhPsmf0T21HspgLf98aZL8indREE/X/kwgMNOmEz5YV/RGaXRjtCULN5iv+kcdKfuKzpPdKsfur0BwOFiDRHkyQDXXvZ8mWzW0ngAv3W8/eFTsTEQHFw2jj93s59piUk/49fbAVj0NLfpMIaZTeDK1djKa+iPkiTmuG8xrybqRq2pHyAvcAZC18NU4bexbsXFcqQ5WsyN9lWpK4cvvs0cWsljXRQsF+i052vFR7aEUK1aeYrMGBw2+2kiS6Jw+SGPAqNGW3Qqfdk1EAI+ZgQbUslLoGiy+aPNNnOUut+RR3JVSR3UpuJhaG3vBnXOpQ5EIBk/mmYqISdrj4OjJUpiE9CvQ15tUWNFCznWm7J+iI5KhGDqVy/EVALN/st7f2AGAH3J5eyVr4r+LeNOQOqCCTs6zPIhAc563D6jpAtSAsT8pssHYHguvwoS5IamTmXYfCfglVXwErCcV/S8HEayqZKXHIkAVMeCsCbvdC3oJuyHEvhbn7XDNuqWh8I/O1tEoHCOuhIxikIjCb6SwRluGgkp1tjmhvu/rufVziLQAPRfdFS6WgofIWm/TzRywHLDeTbuPLOLb41mtuotWaqs9YfLCucvQIFgVQRE+p6M3wrVHeldrO9QEcPgDKmYu0HMz+Zen66a7fov0ALrXP7MLDEZ9cQxb/PeLJe8EvlXjrt6RMkDXnwGESmAF7G1GpamYZ2LeHc3xTbNsDaUJ4v55xL5Y9Y1KkG 5sMNXjHW OYXVWwxTHO6y4TV646KQxvUeFferyK7n/OZrdEFc0ZnE4xDZaXXqRv4X1JIttC5l9issMzjW3ygoh5AxxW3nXkVtukWf7IpoKXlXQxC92bMBbvP5PRSJywVZJYyuFn+jcxmKGD5Po7/g3QzCadrt6juuwhoD4AWn6gQWWlRkXBQw/KihnnAdocDwvVgV2U8xo3UymFTOJsJ1gW92a6geU/hRzKNgMWyQAmNbSztKfNOG5v0LGVJptCc081d/uTv7d8hFrbomy9NCaKUaoRqwx/45VOoJr2ply1McUP1s0K/2aFNY= 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/2/13 16:49, Yosry Ahmed wrote: > On Fri, Feb 9, 2024 at 4:00 AM wrote: >> >> From: Chengming Zhou >> >> All LRU move interfaces have a problem that it has no effect if the >> folio is isolated from LRU (in cpu batch or isolated by shrinker). >> Since it can't move/change folio LRU status when it's isolated, mostly >> just clear the folio flag and do nothing in this case. >> >> In our case, a written back and reclaimable folio won't be rotated to >> the tail of inactive list, since it's still in cpu lru_add batch. It >> may cause the delayed reclaim of this folio and evict other folios. >> >> This patch changes to queue the reclaimable folio to cpu rotate batch >> even when !folio_test_lru(), hoping it will likely be handled after >> the lru_add batch which will put folio on the LRU list first, so >> will be rotated to the tail successfully when handle rotate batch. > > It seems to me that it is totally up to chance whether the lru_add > batch is handled first, especially that there may be problems if it > isn't. You're right, I just don't know better solution :) > >> >> Signed-off-by: Chengming Zhou >> --- >> mm/swap.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/mm/swap.c b/mm/swap.c >> index cd8f0150ba3a..d304731e47cf 100644 >> --- a/mm/swap.c >> +++ b/mm/swap.c >> @@ -236,7 +236,8 @@ static void folio_batch_add_and_move(struct folio_batch *fbatch, >> >> static void lru_move_tail_fn(struct lruvec *lruvec, struct folio *folio) >> { >> - if (!folio_test_unevictable(folio)) { >> + if (!folio_test_locked(folio) && !folio_test_dirty(folio) && >> + !folio_test_unevictable(folio) && !folio_test_active(folio)) { > > What are these conditions based on? I assume we want to check if the > folio is locked because we no longer check that it is on the LRUs, so > we want to check that no one else is operating on it, but I am not > sure that's enough. These conditions are used for checking whether the folio should be reclaimed/rotated at this point. Like we shouldn't reclaim it if it has been dirtied or actived. lru_move_tail_fn() will only be called after we isolate this folio successfully in folio_batch_move_lru(), so if other path has isolated this folio (cpu batch or reclaim shrinker), this function will not be called. > >> lruvec_del_folio(lruvec, folio); >> folio_clear_active(folio); >> lruvec_add_folio_tail(lruvec, folio); >> @@ -254,7 +255,7 @@ static void lru_move_tail_fn(struct lruvec *lruvec, struct folio *folio) >> void folio_rotate_reclaimable(struct folio *folio) >> { >> if (!folio_test_locked(folio) && !folio_test_dirty(folio) && >> - !folio_test_unevictable(folio) && folio_test_lru(folio)) { >> + !folio_test_unevictable(folio) && !folio_test_active(folio)) { > > I am not sure it is safe to continue with a folio that is not on the > LRUs. It could be isolated for other purposes, and we end up adding it > to an LRU nonetheless. Also, folio_batch_move_lru() will do This shouldn't happen since lru_move_tail_fn() will only be called if folio_test_clear_lru() successfully in folio_batch_move_lru(). Thanks.