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 38B4EC48BC1 for ; Wed, 14 Feb 2024 18:59:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE9738D0014; Wed, 14 Feb 2024 13:59:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B98898D0001; Wed, 14 Feb 2024 13:59:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A12648D0014; Wed, 14 Feb 2024 13:59:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 90D588D0001 for ; Wed, 14 Feb 2024 13:59:07 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 59DC880EF3 for ; Wed, 14 Feb 2024 18:59:07 +0000 (UTC) X-FDA: 81791321934.13.1E06895 Received: from mail-yb1-f202.google.com (mail-yb1-f202.google.com [209.85.219.202]) by imf20.hostedemail.com (Postfix) with ESMTP id 96C1A1C0006 for ; Wed, 14 Feb 2024 18:59:05 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=c9lzG+RL; spf=pass (imf20.hostedemail.com: domain of 3eA3NZQoKCPs1rvu1dkphgjrrjoh.frpolqx0-ppnydfn.ruj@flex--yosryahmed.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3eA3NZQoKCPs1rvu1dkphgjrrjoh.frpolqx0-ppnydfn.ruj@flex--yosryahmed.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707937145; a=rsa-sha256; cv=none; b=z+BrzSl5uYNPzB6Jx2JwddcID2nQbJvqv+I27NPlWvKu0Lc608ZBZK0DsQ+CpiK7KVHEii bF40iFw4twClnd60vEBS4Gh9q+ktLJyMMdtMLIBUIg74SdrJycn0SqxEIAXdfNi2zOaYzV eC9si08aXW32N6TA4sMqn0wkR0d4XHg= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=c9lzG+RL; spf=pass (imf20.hostedemail.com: domain of 3eA3NZQoKCPs1rvu1dkphgjrrjoh.frpolqx0-ppnydfn.ruj@flex--yosryahmed.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3eA3NZQoKCPs1rvu1dkphgjrrjoh.frpolqx0-ppnydfn.ruj@flex--yosryahmed.bounces.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=1707937145; 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=8cy/7mXMaq79M/86eaI7actCw/L/OIE+F6++hCFelo0=; b=pea+K4KfkWRVfq5KfHtKMerc2Z8VxVGOQdYkpkJWp/5LxOP3wodDVAPbNjnsSheTQEUSMw eTmLf2WLJL4eudXQA87XPTxPwPAlYHRVrpDCtc14EBdY8SGUTvbNmH/Fi9QLVVIdvrkHol HFF6C/QlYLR1OgIOciXqlkc7aypo+Zc= Received: by mail-yb1-f202.google.com with SMTP id 3f1490d57ef6-dc74645bfa8so3563433276.1 for ; Wed, 14 Feb 2024 10:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707937144; x=1708541944; darn=kvack.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=8cy/7mXMaq79M/86eaI7actCw/L/OIE+F6++hCFelo0=; b=c9lzG+RLHsvrlhgDguPQ3URu8/slMfuxRFSxc6Uay+Jzd2yvhg5AnnMnRswYDDz3CA J4nNvsxIN30/ZG0UetNg3EvvCBvLNIjdBlPt4tq5jSviGqoXOrtZJrW54lchvhCXTObK xQ7ZfDpyKA2w6PumF4yF4H2UrRfom5Ox6lgFABhle/Ab5wTeb4aGftQ6rZyfA+fN5zOi gkllmrlsOFohwAR6+s6IW/93WsPoiWwod7CE6eoPe75+Xpec6PGjuD2bFusv/IMuX1E9 xaaIJM+sgvkWdppt7B52aHstWaBVb/sxqrouO9uokP1cG+nndesmW9cqaWfrZ1nuWl4z isBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707937144; x=1708541944; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=8cy/7mXMaq79M/86eaI7actCw/L/OIE+F6++hCFelo0=; b=HZzfnll7/XMUWRlAUNmUkz+SG3SJ6LFu30h6NCqgAqbQ6AWw5PoPI1nfeiUeA/Itn6 QG5viiVRWv0zvCqVa9o5zjps+jM6n3mdA/4EhcRXC99IIvPAsEpobU8vHMB38ZNwgUqm CUC9qt+QcpyCtusxcD+SdZtHngPHs9ZvMyEm/tjQJnhITYEzi1KoLKsGa9yBnfv7f2HO BBK/9o2JF6uuJ5BEppDK/BujsM7kj1K+aRJbx91phAjodkk/9KUUQm3kNsom5uCqEiIl eYO2KkXHEzUGJNy1VTet8iEb+8HI83lFhYQMkTCxvcLIMdjmr1R3i3Sb/17H12NaYSsU OXCw== X-Forwarded-Encrypted: i=1; AJvYcCUlOQ02M1HPEceo6I98HNtCy0ByCF556BHqWPPuCZwDylJe78hIiNh0aFDUasdZkQ0wbwm+c1Vc71PgUKpTdF6BKgk= X-Gm-Message-State: AOJu0Ywsedpe8+XjoYjb9ps6z4c584uQ6hpKlyGdSu5lsgKIIFAISVZS pSUoXCzu0pFRJbuXEKLb5HS9tbbEtsHx2o/gqQKdo4LtvU/CAzTDtp6W2zFDyO5GmAHICRQ2Mf3 E9TeNAFFY/W0M+r28cA== X-Google-Smtp-Source: AGHT+IHSlBCRYHEyQoZ4CfxjV2Aj/enfQ4vJKY+6w4oEFPd9x/LV7DNhFahImFW0J8drZSJiyHAVJiJqQZIDQ2RK X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:29b4]) (user=yosryahmed job=sendgmr) by 2002:a05:6902:1885:b0:dcc:41ad:fb3b with SMTP id cj5-20020a056902188500b00dcc41adfb3bmr101625ybb.10.1707937144674; Wed, 14 Feb 2024 10:59:04 -0800 (PST) Date: Wed, 14 Feb 2024 18:59:02 +0000 In-Reply-To: <3f7490bb-a36e-46aa-b070-7e6e92853073@linux.dev> Mime-Version: 1.0 References: <20240209115950.3885183-1-chengming.zhou@linux.dev> <20240209115950.3885183-2-chengming.zhou@linux.dev> <3f7490bb-a36e-46aa-b070-7e6e92853073@linux.dev> Message-ID: Subject: Re: [PATCH RFC 1/1] mm/swap: queue reclaimable folio to local rotate batch when !folio_test_lru() From: Yosry Ahmed To: Chengming Zhou 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 96C1A1C0006 X-Stat-Signature: jtufwup7pm6ng5wosmzo13wb3jbanmab X-Rspam-User: X-HE-Tag: 1707937145-609638 X-HE-Meta: U2FsdGVkX19li0zUQMmtdCZTvBSUOf5RCV/Jvpdff14S6tqTDf/LUpR2Iaw/5VGgfllDUR8G8kLMarUzke1YQL3r2WLRCs60bOCmxuPBXz6TikRCs/8pPZ/zkv2pmVaRKrQsOmT11vXRODJMbxWBpNoyoDUtFvtDpNqR0EAmijDv57NYH8uU2D7LmR5O9aJecBqFiWFuFPkzlL1ZaR5qSCstspDXACd6lhQEOk1P8Pj76hwO3WDVdUrlDOoJU/MS0EZd+eawfjo/PGqJVrpZGF/smW0yM1KHmffTQ07alM0NR9SnngHtlqkHfAetIwMik5t+118+UXZz18/nuJBubUF21Bk1mU64MdnE0jzJMn32yuMFCWfNDB1S+ZbATaqdDMLLOKagQk45Ogp1uze//tDpWBReGkZjLrdkdImaRvvwvEfE3SKywt6tIh+PF6A8SQ1jTAvDMNksIamoDHFoCfRcgrYQyGrGuvNNaBCBmJ6b/SbBDmbRwi/zTUFKw6LWJqaTj1PJj1plz3y1xCgYA6GadZWfwQ6L5U6xAZecme9kRUqcgr1daLtda/5DIrY6eh8qjAZfqwF4R5kpGgp1udOU+e7OZ+ynTDACTcD3pWUmDziGX6Vp4koVYZS0h91/X4tD/0urUgzMvHkpTZ086BZPXvzyJ22lpgHEZTMeGtQfSQSLfdIRUzBphnP6VndKhO4euZ3a1s6AgpUzkAgjXPcVn6boytnJ1a2CrsSiO/6Fse1rvMfEGvWpHP1FM9Y5Sbjrg02SUsJ82KoCk5XiCqjOC5BF6Bp3Tf7xV5zNaQV2c1S4lQugGW7WM7MqJ/ZdZp0VNvFBBq7s8exwWUlCGCYYaDnPqGr5o/RQxece4Q4a3Qbrz8D2VjrAiL7hn1ulsWe0llOgGuoXfb0BBmuBJHuf4+niesLWP3FCtETknJCQiXxWh9PCFrwOaknlFSUL6ilPr9zf4aB4scKT4Ly 8cTPZKYB y5vYOnTQW4M3AL3pVMul+KSiIEF0xlpCx2qSwHmf4PyVlnuBks8levgxUmrUDAwKDxCEco373zkL0WhMmxHsGK/Xp1UConRXMQPElI9sbYJizJAR7LheeKg/RwrGrm+APIUfmFJI9X7F90eH58LBa4JL7T1Mrv+p1wNC9YnmQwfFRD/jH6vvB2zBl2sI1dGFrv5XrNZ46GEpb5MUtTzs12D7lFqy8cOr+6PXRRGN/uqxZlntOzdsxDKtKCs0jc2/+Qngqc2rg537s4+UWZaO4kgXAnJevXUiivpxYPt2wc2ZdYmOjfJJoO3rxmormHuf4njOoGglcHjZuqPz0Apjf0RqNSXlqpbrO2RQ+Tb7IoxTsdlBV2OZ96PyIbdCCcWy8yVDPKN5q6zZP0+uYCKF6wzGx+C2ioFQX/DGc+WA2JH0KR3xMme/vMsNBCE3L6DypFhT9dcJtNB28DyuaSboxS0oDLd6t+bt4v83SZ6L2a1aaF3yakfvzEnp5F5lOTQDqLDmXysgo7OWHTNTEHeFUOTDYuBmfdIFS/M1Baogz/bV+HlEDHRTe4mNbl7CoTTiNo42ykt8fL5REHjSsf7FPE37qjFZQkq0S43wZ2vbDLomnyteAZvjIjZJiXHc8Ym6jIUmFBgWw2v8faFAyWDb2RHtqYi7y1BHLozLA4B/D/RBjS8GlyzVdUd9aGVk0MPBz1W5dfY4/CAAps8F+DpLD0t4Wgi4HqzcJWzozEcfke60T3nHu5h3hJeHtXyxb0p6PvalRMs+Xryhik2E4q4BEvLfAX/nB67PlRHRnzDCoJtNcvvY= 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 Wed, Feb 14, 2024 at 05:54:56PM +0800, Chengming Zhou wrote: > On 2024/2/13 16:49, Yosry Ahmed wrote: > > On Fri, Feb 9, 2024 at 4:00=E2=80=AFAM 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. > >=20 > > 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. >=20 > You're right, I just don't know better solution :) >=20 > >=20 > >> > >> 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 *fol= io) > >> { > >> - if (!folio_test_unevictable(folio)) { > >> + if (!folio_test_locked(folio) && !folio_test_dirty(folio) && > >> + !folio_test_unevictable(folio) && !folio_test_active(folio= )) { > >=20 > > 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. >=20 > These conditions are used for checking whether the folio should be reclai= med/rotated > at this point. Like we shouldn't reclaim it if it has been dirtied or act= ived. This should be explained somewhere, a comment or in the commit message. =20 > lru_move_tail_fn() will only be called after we isolate this folio succes= sfully > in folio_batch_move_lru(), so if other path has isolated this folio (cpu = batch > or reclaim shrinker), this function will not be called. Interesting, why are we checking if the folio is locked here then? >=20 > >=20 > >> 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= )) { > >=20 > > 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 >=20 > This shouldn't happen since lru_move_tail_fn() will only be called if > folio_test_clear_lru() successfully in folio_batch_move_lru(). I see, so this is where we hope lru_add batch gets handled first. I need to think about this some more, let's also see what others like Yu say. Thanks!