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 8C420C48BC3 for ; Sun, 18 Feb 2024 02:47:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6F476B0089; Sat, 17 Feb 2024 21:47:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B1FCA6B008A; Sat, 17 Feb 2024 21:47:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E7096B0092; Sat, 17 Feb 2024 21:47:16 -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 8D25D6B0089 for ; Sat, 17 Feb 2024 21:47:16 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5E8AA120120 for ; Sun, 18 Feb 2024 02:47:16 +0000 (UTC) X-FDA: 81803388072.25.FDAAA6C Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) by imf06.hostedemail.com (Postfix) with ESMTP id 367B5180009 for ; Sun, 18 Feb 2024 02:47:13 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=rIOGwIXJ; spf=pass (imf06.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.176 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=1708224434; 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=7QXfOY0s0er1gZrkY/W4CgNq8aUNS6EDhavdkRc5tvU=; b=S8Wc7REbYiv8HLSfgTWV4rJAkYzWbneWCiBRdzoxG9UA6zDgkzOwM5HxRfyePgfIqpcFOf gVBKvVbR4wD3jvga9utqHpvi/MhZi3F6+wiPBkvi/JTVqlUhukj9OZNj49Z/9IfJHjJQGd YDXw/InadLR9XQw1gvFpXF1uZom2ZTo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708224434; a=rsa-sha256; cv=none; b=L7IgVODqkiLs0mJrjzOgVI4MQ7wBy0dXGcpDxBtmMphFSSJIWCusH2G9aEo6ydzMm96V4H NVq6GaG06AT1QJ+DmFdfZW4UNjwLGiAcrwrxn4qgtdgwWe23SjJQhRL/ylu5VuIcCbGFpX 71txwZym4/qu8loCCkZJzWODSmh+JRc= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=rIOGwIXJ; spf=pass (imf06.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.176 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Message-ID: <56710a26-2cf4-4116-8181-4fa1ce084008@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1708224432; 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=7QXfOY0s0er1gZrkY/W4CgNq8aUNS6EDhavdkRc5tvU=; b=rIOGwIXJkN5pwF6MUP/wnDMMPhiNI0iZnA3rc0H+eIB4Qq5cMQHFT8aRnSpP5ytl7zGirH J/YEJFhpIbPJpP3RiBtRGGm/yibX4D/xK/0HexCC7/seA4TelbXmAbTL/T0QDqkXl1/tU7 maLQQizeE1xX+aJT/BNrDiFM6PCbd3g= Date: Sun, 18 Feb 2024 10:46:41 +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> <3f7490bb-a36e-46aa-b070-7e6e92853073@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-Stat-Signature: 5rdez3j8keq5kikafsyhsprjn7a99awi X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 367B5180009 X-Rspam-User: X-HE-Tag: 1708224433-514923 X-HE-Meta: U2FsdGVkX185K7OMpSu/dnVKx0xQYHTplFkRM2P2faEHvhJhviQvPjlq9Smg2fhG8qMotNmhLnjFQC5Mgw36i/C92H5BIMEllpjoldC3E//CqTK5DOzgvi0yNFolPJNoNKi8N5hwuw+aTIYbjJss6XJsrT0b0ZGCD5SIgp/lUEwAulbGDbG50YRtQ+/RAPtjh+NFcdmwHRnav6s1nOUo/wrfHKsABuiGVf1sCvJPAB5RWiHKHiXmMSgvzeeFWNma2lMwRsS91FKeKy3MOTMZwA9PcWPE17lgnlJOCiG61oEGvOsuKFFN+3q0tgtCAjANnwU1AE9NV5qwhESUqZNwwFvBUCm26hpthVXIkJgZerksLRIjRjGu1RirJSQr8nA4E4u4wMGBY5kWdtY4XJQjsrS/13vq/gvBJKo6DMDZwtGQqHCyWXEPH0pa8Jsn8RYM4hajio/hBIP/CapBAug9ZD87CtmMvtp3beJ9atF1UzMcin7a83mrwYqAHpe0tJrs1CbTK7h25Y1Mh56x997jgOL/64415yiU12lerg8LzPGROTmQOwXRxhJjogbPcO4vY89bI7M0Q5rUP+pRZe7wDTadrYYzXKVbzMBXXSpgBGA2+eJUWVgf9RRqVcEr3KfAP2pir71X3sdujH6CG2OSP1zT0TMZspMMxWtl3U/jAUG+Dlvf0Z823p/wJxZDOwxAYxz7dotuUF+FJ1P7dWwW6PmT3/lXXTyCayIiH+wtZO8Z+zXo81jHZtW4iMnYIzbUoN0u0phrt6SM/G/yifYzRW8K00X9j02/UOLjRxRE+n1p+aRw/ubi8rK0TGLTNMR54ZRgYwUL4yv6f3jCyd7y13x9rOg7IM0dfv/T9s9A9QUKK0EFJgCWMGBnqyLH5A+SCw2Y16Bs1m7vmZomJeeHKwGtmkalNDrBIVYiVV0txOYLLIKcVMbLcFKiyDeT2vMZmU/Sj1FASp2ACYYz+G5 otDRSSGO TOmPY2NaYu+HLgdgXQH4Ew7wjEPrYMb9OEEedzQAsCWCuRm2gIQ5694dKYiUZToporvZ/31elRCIAnpBVWycVZ71t8HXIK/yDkej8Z8HUArLNjPAU7HRf4xqBs26PF4cXlr1G8EAZMw/s9AY/uSvhw8uEx7ay5QDJ0goFDaFIYIqoCpe2yTI+8AyO6DjSt7Bq4jIzIgTNxtTS4Vs60OCIz4UjRgpCDaU6guAD7gJOy3Tzj5RdKL4Mhzek+OefOZJY4akeluO66xIIQVo= 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/15 02:59, Yosry Ahmed wrote: > 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 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. > > This should be explained somewhere, a comment or in the commit message. > >> 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. > > Interesting, why are we checking if the folio is locked here then? I think it means the folio is using by others, and reclaim needs to lock the folio. Not very sure. > >> >>> >>>> 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(). > > 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. Right.