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 B231DC02183 for ; Fri, 17 Jan 2025 08:39:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24FF96B0082; Fri, 17 Jan 2025 03:39:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FEE36B0083; Fri, 17 Jan 2025 03:39:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C73B6B0085; Fri, 17 Jan 2025 03:39:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E98A96B0082 for ; Fri, 17 Jan 2025 03:39:06 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0D239A17F1 for ; Fri, 17 Jan 2025 08:39:06 +0000 (UTC) X-FDA: 83016293892.23.AA68EEB Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) by imf17.hostedemail.com (Postfix) with ESMTP id 54FFC40016 for ; Fri, 17 Jan 2025 08:39:03 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NvG7QDvA; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf17.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=1737103143; a=rsa-sha256; cv=none; b=akNq67LOV1t3nPJbn8rHw31gII1OJzDKRFYcaucdyrWAO8gWIht24yq4EK0DwkseADrMzu A0ktMfa5XeHUwsbVVikXETcI3IiD+yYJd0X2qSX80T4FT8fJNFct2DksB5NsCddm5/01fl ab0RV+CpzNwN57AM9sZWuYNPTWz5s8U= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=NvG7QDvA; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf17.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=1737103143; 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=1dkm5xI63VVw0i0PK1MNJHBKKxRAlTZgMMdxDB33yUg=; b=j3KXKUlZjQO360FUyq2w5pixWqJUL/vcqXPzrZ6ma5b3mjJ9xwoxyEytpSLAte01tPPFKl DRavHFW6bkp+HrMcHZpqv54VRJFLa2THSe3VTMe8T4IlUet3TKGoGsajNkQbHrUYOOOysm +knlPV/wOHJ3K+64TvprzAqSk+MIZWo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737103144; x=1768639144; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=uy8BcdVQj4lUlt1pGtuypx5tRMlIIYJH4Xw1bOGn4lY=; b=NvG7QDvAPk2qYg2VBjHHi9S2gCVlInkAFyGDPI1IjM310pGo2TOppBa5 QfdMH7MPHSWjOUR6kNs3q50z5KSYgbKe9oSGi/eU5HXdkUrdmtQnM+mLC orvzZzRUyL19EdF/AZac9WKp3upNNxzo1gT2wuhDBr4KkJ5Nsm8feg8Si 9vgvdQ9tPcBZGkEIieRZI7+kv3ZwjgGv5cN85KpuVUI/N18W202TPLhEe akc35uGA/k8RiziWaF/o7zhLi3Uud7kXF2vG1qDNSebm68el6YV4NCjTM orQZLfgUqAN7Q178VHX8HSRFNJIZpiS13X+KNbNyThfKpcRdu6l9Eu0gx w==; X-CSE-ConnectionGUID: +9c3KgiOQkig1CbEoJEYwQ== X-CSE-MsgGUID: MWsVELN8SMyRBlI0PO8FEQ== X-IronPort-AV: E=McAfee;i="6700,10204,11317"; a="41294823" X-IronPort-AV: E=Sophos;i="6.13,211,1732608000"; d="scan'208";a="41294823" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jan 2025 00:39:02 -0800 X-CSE-ConnectionGUID: 61Goo4gqR2i2GCCEPc+/Kg== X-CSE-MsgGUID: +lDePOewTJmUoUeXzNRQJA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="110381817" Received: from black.fi.intel.com ([10.237.72.28]) by fmviesa005.fm.intel.com with ESMTP; 17 Jan 2025 00:38:54 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id 2C8E610F; Fri, 17 Jan 2025 10:38:53 +0200 (EET) Date: Fri, 17 Jan 2025 10:38:53 +0200 From: "Kirill A. Shutemov" To: Yu Zhao Cc: Matthew Wilcox , Andrew Morton , 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 , Yosry Ahmed , 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: [PATCHv2 05/11] mm/truncate: Use folio_set_dropbehind() instead of deactivate_file_folio()k Message-ID: References: <20250115093135.3288234-1-kirill.shutemov@linux.intel.com> <20250115093135.3288234-6-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-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 54FFC40016 X-Stat-Signature: h37n9473hwzg1kxbka3di6yay6j7569k X-HE-Tag: 1737103143-762676 X-HE-Meta: U2FsdGVkX18kUcsAqOGHZ1AGyYgiW8BYX7vMyGV/szE/qbi0ba1+P47rqjOlwvttOrdnkszA6FVvgCLnInchnhrXo+Uvhu2xLJp5JsryiHej0aFwcRDCI3eehXyw8k+TAnersNyNt3A+zaNlWAuvzD+5for0JvETP7mtM7GFTBn9XgZleTUDJm/8I26eoSYcEb4WdqvF5HYDYOzuJcaCW8KSlDneyoTNKeCVylYRJz3dGKOcj970qblhQ4+RsSZfLXp7QurIFXfPXOXGkiq3koCqdCuCsNrf9OAmV0g3mgR50WuDugEbAFtL9lhJQtRqJUI7m3BAQ4cffhJ/0ArPtX4WgF8l3fcnJHm1Xjn8sH/7imTkKEGSAoS2Toto3rWb7Uv4TD5ZwMc4BTz6LC3oxavZG3n0wssqeS2cuymcuYrCKPozM2yQRh31YYkgLNl+yF6FV8xjZfYuy7eOPfCVrnfT9pp+gFuSiNT1ql/+NlmG/SRszCBOIfe1L5MeAKDNuyjH8FQ4qbB1Bpo/pheb45EFQPXHviXhydXI7OiQTNsm7saYVqmlAIx2tgxdhi0Ypgk7HQsKBWHBToHa9XTqtcqN7/Cnza5cLz5no3SNS2y6pphkRO13aakG7e9IfgU7kv2zISEL/owA6HAk06OGVOQ9XkqtbF3+XaX1T9ZoxEe6rCCVo/XBtqdzt5U5fFeOko/fbHQurixTTm5BWqPyfo42twGNZQp5PUh7mR/zvY3U8R+Ba7g1n1Bhuptj5phqz9PVJRs72wpI9rCHlL3I/fBhGBjr9nIC25m5baakc5boJrKduV5/R3ULapbx8752j5oH9knRqPaBhnUwdmaoLgK/59sRE7onvirFX/bWL9YLtiEZTEqC7FNckqyP07QGShRGvcOr4x2hd1v9J++BBlV9gHqeG04KfA6NxLw9HV1IdxX467HU/57pPI9XMmS3pWoE5e3/IRQkKr4OH9N dOio7vtj kDEzVXOAYc2do2QkTNEawieqR6bSHpO4x8Y1kJzO8W7Qd4U3NKYno75P4fKlo0cio3HPAZYdFDZRt0TeXdbfgrEimW1OM2+e5X8VmxHoavRNlTEfF8H9/7p3BII4KRRFyi0W1FOG9r5SmYTav24xOWLvlJJ29VrbTpuadvEgriUvjF3bbOnSiHtIu5sOTI7eDpT9I6A52/U0J+3MRZk3VcIa7lkeUh1ys4Til6A3Z7mpAEpWtOhDtuwcBdCfOzM2nWU3DB2K3WEaQ9BvLLyrMI559D8lVrUGpwwmdK8qxU2QuUoioio31S5ZpLnEuafXN1zEx 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, Jan 15, 2025 at 02:46:44PM -0700, Yu Zhao wrote: > On Wed, Jan 15, 2025 at 2:35 PM Matthew Wilcox wrote: > > > > On Wed, Jan 15, 2025 at 11:31:29AM +0200, Kirill A. Shutemov wrote: > > > -static void lru_deactivate_file(struct lruvec *lruvec, struct folio *folio) > > > -{ > > > - bool active = folio_test_active(folio) || lru_gen_enabled(); > > > - long nr_pages = folio_nr_pages(folio); > > > - > > > - if (folio_test_unevictable(folio)) > > > - return; > > > - > > > - /* Some processes are using the folio */ > > > - if (folio_mapped(folio)) > > > - return; > > > - > > > - lruvec_del_folio(lruvec, folio); > > > - folio_clear_active(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); > > > - } else { > > > - /* > > > - * The folio's writeback ended while it was in the batch. > > > - * We move that folio to the tail of the inactive list. > > > - */ > > > - lruvec_add_folio_tail(lruvec, folio); > > > - __count_vm_events(PGROTATED, nr_pages); > > > - } > > > - > > > - if (active) { > > > - __count_vm_events(PGDEACTIVATE, nr_pages); > > > - __count_memcg_events(lruvec_memcg(lruvec), PGDEACTIVATE, > > > - nr_pages); > > > - } > > > -} > > > > > +++ b/mm/truncate.c > > > @@ -486,7 +486,7 @@ unsigned long mapping_try_invalidate(struct address_space *mapping, > > > * of interest and try to speed up its reclaim. > > > */ > > > if (!ret) { > > > - deactivate_file_folio(folio); > > > + folio_set_dropbehind(folio); > > > > brr. > > > > This is a fairly substantial change in semantics, and maybe it's fine. > > > > At a high level, we're trying to remove pages from an inode that aren't > > in use. But we might find that some of them are in use (eg they're > > mapped or under writeback). If they are mapped, we don't currently > > try to accelerate their reclaim, but now we're going to mark them > > as dropbehind. I think that's wrong. > > > > If they're dirty or under writeback, then yes, mark them as dropbehind, but > > I think we need to be a little more surgical here. Maybe preserve the > > unevictable check too. > > Right -- deactivate_file_folio() does make sure the folio is not > unevictable or mapped. So probably something like below would the > change in semantics be close enough? > > if (!folio_test_unevictable(folio) && !folio_mapped(folio)) > folio_set_dropbehind(folio); Okay, makes sense to me. -- Kiryl Shutsemau / Kirill A. Shutemov