From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To: Andrew Morton <akpm@linux-foundation.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Jens Axboe <axboe@kernel.dk>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andi Shyti <andi.shyti@linux.intel.com>,
Chengming Zhou <chengming.zhou@linux.dev>,
Christian Brauner <brauner@kernel.org>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Dan Carpenter <dan.carpenter@linaro.org>,
David Airlie <airlied@gmail.com>,
David Hildenbrand <david@redhat.com>, Hao Ge <gehao@kylinos.cn>,
Jani Nikula <jani.nikula@linux.intel.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Josef Bacik <josef@toxicpanda.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Miklos Szeredi <miklos@szeredi.hu>, Nhat Pham <nphamcs@gmail.com>,
Oscar Salvador <osalvador@suse.de>,
Ran Xiaokai <ran.xiaokai@zte.com.cn>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Simona Vetter <simona@ffwll.ch>,
Steven Rostedt <rostedt@goodmis.org>,
Tvrtko Ursulin <tursulin@ursulin.net>,
Vlastimil Babka <vbabka@suse.cz>,
Yosry Ahmed <yosryahmed@google.com>, Yu Zhao <yuzhao@google.com>,
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: [PATCHv2 05/11] mm/truncate: Use folio_set_dropbehind() instead of deactivate_file_folio()
Date: Wed, 15 Jan 2025 11:31:29 +0200 [thread overview]
Message-ID: <20250115093135.3288234-6-kirill.shutemov@linux.intel.com> (raw)
In-Reply-To: <20250115093135.3288234-1-kirill.shutemov@linux.intel.com>
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.
The new flag allows to replace whole deactivate_file_folio() machinery
with simple folio_set_dropbehind().
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
mm/internal.h | 1 -
mm/swap.c | 90 ---------------------------------------------------
mm/truncate.c | 2 +-
3 files changed, 1 insertion(+), 92 deletions(-)
diff --git a/mm/internal.h b/mm/internal.h
index 109ef30fee11..93e6dac2077a 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -379,7 +379,6 @@ static inline vm_fault_t vmf_anon_prepare(struct vm_fault *vmf)
vm_fault_t do_swap_page(struct vm_fault *vmf);
void folio_rotate_reclaimable(struct folio *folio);
bool __folio_end_writeback(struct folio *folio);
-void deactivate_file_folio(struct folio *folio);
void folio_activate(struct folio *folio);
void free_pgtables(struct mmu_gather *tlb, struct ma_state *mas,
diff --git a/mm/swap.c b/mm/swap.c
index fc8281ef4241..7a0dffd5973a 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -54,7 +54,6 @@ struct cpu_fbatches {
*/
local_lock_t lock;
struct folio_batch lru_add;
- struct folio_batch lru_deactivate_file;
struct folio_batch lru_deactivate;
struct folio_batch lru_lazyfree;
#ifdef CONFIG_SMP
@@ -524,68 +523,6 @@ void folio_add_lru_vma(struct folio *folio, struct vm_area_struct *vma)
folio_add_lru(folio);
}
-/*
- * If the folio cannot be invalidated, it is moved to the
- * inactive list to speed up its reclaim. It is moved to the
- * head of the list, rather than the tail, to give the flusher
- * threads some time to write it out, as this is much more
- * effective than the single-page writeout from reclaim.
- *
- * If the folio isn't mapped and dirty/writeback, the folio
- * could be reclaimed asap using the reclaim flag.
- *
- * 1. active, mapped folio -> none
- * 2. active, dirty/writeback folio -> inactive, head, reclaim
- * 3. inactive, mapped folio -> none
- * 4. inactive, dirty/writeback folio -> inactive, head, reclaim
- * 5. inactive, clean -> inactive, tail
- * 6. Others -> none
- *
- * In 4, it moves to the head of the inactive list so the folio is
- * written out by flusher threads as this is much more efficient
- * than the single-page writeout from reclaim.
- */
-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);
- }
-}
-
static void lru_deactivate(struct lruvec *lruvec, struct folio *folio)
{
long nr_pages = folio_nr_pages(folio);
@@ -652,10 +589,6 @@ void lru_add_drain_cpu(int cpu)
local_unlock_irqrestore(&cpu_fbatches.lock_irq, flags);
}
- fbatch = &fbatches->lru_deactivate_file;
- if (folio_batch_count(fbatch))
- folio_batch_move_lru(fbatch, lru_deactivate_file);
-
fbatch = &fbatches->lru_deactivate;
if (folio_batch_count(fbatch))
folio_batch_move_lru(fbatch, lru_deactivate);
@@ -667,28 +600,6 @@ void lru_add_drain_cpu(int cpu)
folio_activate_drain(cpu);
}
-/**
- * deactivate_file_folio() - Deactivate a file folio.
- * @folio: Folio to deactivate.
- *
- * This function hints to the VM that @folio is a good reclaim candidate,
- * for example if its invalidation fails due to the folio being dirty
- * or under writeback.
- *
- * Context: Caller holds a reference on the folio.
- */
-void deactivate_file_folio(struct folio *folio)
-{
- /* Deactivating an unevictable folio will not accelerate reclaim */
- if (folio_test_unevictable(folio))
- return;
-
- if (lru_gen_enabled() && lru_gen_clear_refs(folio))
- return;
-
- folio_batch_add_and_move(folio, lru_deactivate_file, true);
-}
-
/*
* folio_deactivate - deactivate a folio
* @folio: folio to deactivate
@@ -772,7 +683,6 @@ static bool cpu_needs_drain(unsigned int cpu)
/* Check these in order of likelihood that they're not zero */
return folio_batch_count(&fbatches->lru_add) ||
folio_batch_count(&fbatches->lru_move_tail) ||
- folio_batch_count(&fbatches->lru_deactivate_file) ||
folio_batch_count(&fbatches->lru_deactivate) ||
folio_batch_count(&fbatches->lru_lazyfree) ||
folio_batch_count(&fbatches->lru_activate) ||
diff --git a/mm/truncate.c b/mm/truncate.c
index e2e115adfbc5..864aaadc1e91 100644
--- a/mm/truncate.c
+++ 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);
/* Likely in the lru cache of a remote CPU */
if (nr_failed)
(*nr_failed)++;
--
2.45.2
next prev parent reply other threads:[~2025-01-15 9:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 9:31 [PATCHv2 00/11] Get rid of PG_reclaim and rename PG_dropbehind Kirill A. Shutemov
2025-01-15 9:31 ` [PATCHv2 01/11] mm/migrate: Transfer PG_dropbehind to the new folio Kirill A. Shutemov
2025-01-15 9:31 ` [PATCHv2 02/11] drm/i915/gem: Convert __shmem_writeback() to folios Kirill A. Shutemov
2025-01-15 9:31 ` [PATCHv2 03/11] drm/i915/gem: Use PG_dropbehind instead of PG_reclaim Kirill A. Shutemov
2025-01-15 9:31 ` [PATCHv2 04/11] mm/zswap: " Kirill A. Shutemov
2025-01-15 9:31 ` Kirill A. Shutemov [this message]
2025-01-15 20:43 ` [PATCHv2 05/11] mm/truncate: Use folio_set_dropbehind() instead of deactivate_file_folio() Yu Zhao
2025-01-15 21:35 ` Matthew Wilcox
2025-01-15 21:46 ` Yu Zhao
2025-01-17 8:38 ` [PATCHv2 05/11] mm/truncate: Use folio_set_dropbehind() instead of deactivate_file_folio()k Kirill A. Shutemov
2025-01-15 9:31 ` [PATCHv2 06/11] mm/vmscan: Use PG_dropbehind instead of PG_reclaim Kirill A. Shutemov
2025-01-15 9:31 ` [PATCHv2 07/11] mm/vmscan: Use PG_dropbehind instead of PG_reclaim in shrink_folio_list() Kirill A. Shutemov
2025-01-15 9:31 ` [PATCHv2 08/11] mm/mglru: Check PG_dropbehind instead of PG_reclaim in lru_gen_folio_seq() Kirill A. Shutemov
2025-01-15 9:31 ` [PATCHv2 09/11] mm: Remove PG_reclaim Kirill A. Shutemov
2025-01-15 20:51 ` Yu Zhao
2025-01-15 9:31 ` [PATCHv2 10/11] mm/vmscan: Do not demote PG_dropbehind folios Kirill A. Shutemov
2025-01-15 9:31 ` [PATCHv2 11/11] mm: Rename PG_dropbehind to PG_reclaim Kirill A. Shutemov
2025-01-15 20:52 ` Yu Zhao
2025-01-16 6:18 ` Christoph Hellwig
2025-01-17 8:42 ` Kirill A. Shutemov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250115093135.3288234-6-kirill.shutemov@linux.intel.com \
--to=kirill.shutemov@linux.intel.com \
--cc=Jason@zx2c4.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andi.shyti@linux.intel.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=chengming.zhou@linux.dev \
--cc=christophe.leroy@csgroup.eu \
--cc=dan.carpenter@linaro.org \
--cc=david@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gehao@kylinos.cn \
--cc=hannes@cmpxchg.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=josef@toxicpanda.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=miklos@szeredi.hu \
--cc=nphamcs@gmail.com \
--cc=osalvador@suse.de \
--cc=ran.xiaokai@zte.com.cn \
--cc=rodrigo.vivi@intel.com \
--cc=rostedt@goodmis.org \
--cc=simona@ffwll.ch \
--cc=tursulin@ursulin.net \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=yosryahmed@google.com \
--cc=yuzhao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®