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 0623AE77188 for ; Tue, 14 Jan 2025 08:12:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 636376B007B; Tue, 14 Jan 2025 03:12:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E5756B0083; Tue, 14 Jan 2025 03:12:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 485886B0085; Tue, 14 Jan 2025 03:12:18 -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 2A6976B007B for ; Tue, 14 Jan 2025 03:12:18 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9B1871C7402 for ; Tue, 14 Jan 2025 08:12:17 +0000 (UTC) X-FDA: 83005339914.21.941A1D3 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) by imf15.hostedemail.com (Postfix) with ESMTP id D0859A000E for ; Tue, 14 Jan 2025 08:12:14 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mApt8OzH; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf15.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.14) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736842335; a=rsa-sha256; cv=none; b=zh4iL1J1XCJXx5/hbTSzcp+AssfzYbnmLFZkdUikvuutN1unBGVdg/8eumYj4rB2VzjTuO 9yFTbWKWxfi8BSvaQkWv+kchMsbARR1Wu3BUs1yqIWO5Kn9O+M7QfA2DArd8Z7Z9LjxsFV iw1qQGyv2fgOmX13iJzyLRJ09gq18vA= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mApt8OzH; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf15.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.14) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736842335; 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=wX6f2YAjzks3a8W60dvBbhrVwNxLeEJIj+KFGJHBS6Q=; b=RjuamgDMWudvz8EqAXo6OUy/2X/vTSwK3/7Lv+Y+xFiESLedQj7+ifWbF4TWTYEJvGiDjr D4q4ny58pEyrmV7i3XDT87p8pLAunGFkbXnnMmfpe8QyNijgEYhpuk+Ll2R2DztNd9hcyI bsZrjjlDk52BNP7mjPhkNvi99AxCArU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1736842335; x=1768378335; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=pxe5Cr3IUU4vuhI2W5Tsk9Ljrj/+VC3k0IJ02hJCG94=; b=mApt8OzHznUf8Q5aDs/97GqP6nWZHWOJb+S/wI/2l8M4iyjinMFbh1K/ izF9Y2PxjUBsdG4n6D+GNXLj0F9NAh4bEo9E36AO6+e3fNq1P7RntYbl/ 2J9DldrITUHkfUUrUTteRivSh1MdZ12XYCs48x/n/AgLcNBpnq8DGTaqX NohZmagjYGC4PUYloTDO87RJO05HusBEbu98lZBPYRgMI/mRZRN29NyoG KDvX1ViL16vlyzBTsab5eYA8SEJqsH4Q7Us46+0ybWYG+RzPPj4loJrW+ ACACWQWA3trzTdZYvBRdandPRPv6JN1FB3zAGmExYADHzbBbzKUjN9qlj w==; X-CSE-ConnectionGUID: oY07ruogQ4OYOSfF9062Bw== X-CSE-MsgGUID: OrIzKtyJT9W8y+aCmYOycw== X-IronPort-AV: E=McAfee;i="6700,10204,11314"; a="40893219" X-IronPort-AV: E=Sophos;i="6.12,313,1728975600"; d="scan'208";a="40893219" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2025 00:12:13 -0800 X-CSE-ConnectionGUID: q+uksDtPR+etdITJ2foqng== X-CSE-MsgGUID: +ZAIAAAPT/WLm4t+jo2BVw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="105220331" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa007.jf.intel.com with ESMTP; 14 Jan 2025 00:12:05 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id 6A55439C; Tue, 14 Jan 2025 10:12:03 +0200 (EET) Date: Tue, 14 Jan 2025 10:12:03 +0200 From: "Kirill A. Shutemov" To: Yosry Ahmed Cc: Andrew Morton , "Matthew Wilcox (Oracle)" , Jens Axboe , "Jason A. Donenfeld" , Andi Shyti , Chengming Zhou , Christian Brauner , Christophe Leroy , Dan Carpenter , David Airlie , David Hildenbrand , Hao Ge , Jani Nikula , Johannes Weiner , Joonas Lahtinen , Josef Bacik , Masami Hiramatsu , Mathieu Desnoyers , Miklos Szeredi , Nhat Pham , Oscar Salvador , Ran Xiaokai , Rodrigo Vivi , Simona Vetter , Steven Rostedt , Tvrtko Ursulin , Vlastimil Babka , Yu Zhao , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH 4/8] mm/swap: Use PG_dropbehind instead of PG_reclaim Message-ID: References: <20250113093453.1932083-1-kirill.shutemov@linux.intel.com> <20250113093453.1932083-5-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D0859A000E X-Stat-Signature: gipwu5hwuqwcbbf7wd6gipmo7pkkmgsy X-Rspam-User: X-HE-Tag: 1736842334-953052 X-HE-Meta: U2FsdGVkX1/Ks41byuB02eZhbTVGTbHEA0sYBRho/CEqPamIkpLDtrFEkFnRW2u5E/SRBho1ckPzmvm0FwoF0ac+42ffp/omk+vSG5pEdVDOg0gwVVFcPdA7cIimGLozDvK3eoc8k4RXkUMGkY0MIDKF2n8DhceIvvQOyjrc2AYtLntCPlJlRB7ZdBFM7e0zNPXndPbv355EYxlYKYKiqXD54zUSnl85xB1zc9c3SaTJK9D8plcJ5EadDRmas4Wfi3pLw8rJVVc4und+GkYiyjO9wPFQ8yyezUM2ZGu7U+qG3xK0XUt/2A416eiuGzZ0ZRfDdGmDqIYRSioKM71eLWErGiomfYI07zZwhODi+z6IzDAedqY+xZt+3q76mRV7w891gf+6dyxluPDYqVlUKfJqX2xsm98DVqKxP08e7in2B3WU6BIehFYnHrJ5SVAieM9EYoYxrsKH6xk3NElLyHlNPbg5sfvYxcFjNfxhPlsJW60KDIlCUU1teDlvnWFsoBwYWH46FDybD7W+qEzb0dOhek8hK317Wyu0G2X8iI/BZUaZa7d5hLot/GGesiGLdMbltj4mQSAZwAamSnuc2+uzdM501OkqSKgTvLOKdDv0rjMSQj0l4Ffgf7JdnHuvumc0+peCALLs2sA58rJKXQ7EMMpcviTjk9eV1MOs6o6Toh45YCrf0FSPZS7YkD6h6T7tjKQJfBpFMjKuoY0u47dSnph6P3nbOeVcJOhzVt8+SGz8WYrxPzJ/sobJWuag0yldoJ9EqtG18/5oBMOU1psUb1Q4yF2SBFW/XQqszkmVKcmgqmigbK9D+YHbFdp1NLPjY/uJonQoKG+cuuH/iP6e3BsUOPnTaz4Tza3il4SLBIT+NAfumhgZg5VYxo+Az8um5oG6X185PTaDVyBal4mosLvv9T0kF5Cn0En8XJo4eBPBpTbRpzL4OY52hdvwvAywJKyczh/6sSpPt/7 RlYm+cos 3D3xyXNb5nEbOWNzzUP3ZBfezc8Sq7bZ9lkH8w7aZzmNuALZoSvsxh/TiWLXaU2KQUBvXBLDC5fQP9UYDBit6fGFr3BUmJ6BGHSzEHUfBfm/FIyy4CJ1aRm18B5BTPyu+8yJKZmB/p/Aztv+2FGPBOBbIvPhE3DqKTNtMf/+mMkohI1n/+fAXbYb1EgzD7CNKycgPk/wMRlQV6yr5u2/S5c3Z78XNdDFScBixQ/i3LMxLg6A4i58QyFJrHSIM/TPmQdWnNBN0wjMRh9SOWpqt6JwIJQ== 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 Mon, Jan 13, 2025 at 08:17:20AM -0800, Yosry Ahmed wrote: > On Mon, Jan 13, 2025 at 1:35 AM Kirill A. Shutemov > wrote: > > > > The recently introduced PG_dropbehind allows for freeing folios > > immediately after writeback. Unlike PG_reclaim, it does not need vmscan > > to be involved to get the folio freed. > > > > Instead of using folio_set_reclaim(), use folio_set_dropbehind() in > > lru_deactivate_file(). > > > > Signed-off-by: Kirill A. Shutemov > > --- > > mm/swap.c | 8 +------- > > 1 file changed, 1 insertion(+), 7 deletions(-) > > > > diff --git a/mm/swap.c b/mm/swap.c > > index fc8281ef4241..4eb33b4804a8 100644 > > --- a/mm/swap.c > > +++ b/mm/swap.c > > @@ -562,14 +562,8 @@ static void lru_deactivate_file(struct lruvec *lruvec, struct folio *folio) > > folio_clear_referenced(folio); > > > > if (folio_test_writeback(folio) || folio_test_dirty(folio)) { > > - /* > > - * Setting the reclaim flag could race with > > - * folio_end_writeback() and confuse readahead. But the > > - * race window is _really_ small and it's not a critical > > - * problem. > > - */ > > lruvec_add_folio(lruvec, folio); > > - folio_set_reclaim(folio); > > + folio_set_dropbehind(folio); > > } else { > > /* > > * The folio's writeback ended while it was in the batch. > > Now there's a difference in behavior here depending on whether or not > the folio is under writeback (or will be written back soon). If it is, > we set PG_dropbehind to get it freed right after, but if writeback has > already ended we put it on the tail of the LRU to be freed later. > > It's a bit counterintuitive to me that folios with pending writeback > get freed faster than folios that completed their writeback already. > Am I missing something? Yeah, it is strange. I think we can drop the writeback/dirty check. Set PG_dropbehind and put the page on the tail of LRU unconditionally. The check was required to avoid confusion with PG_readahead. Comment above the function is not valid anymore. But the folio that is still dirty under writeback will be freed faster as we get rid of the folio just after writeback is done while clean page can dangle on LRU for a while. I don't think we have any convenient place to free clean dropbehind page other than shrink_folio_list(). Or do we? Looking at shrink_folio_list(), I think we need to bypass page demotion for PG_dropbehind pages. -- Kiryl Shutsemau / Kirill A. Shutemov