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: [PATCH 6/8] mm/vmscan: Use PG_dropbehind instead of PG_reclaim in shrink_folio_list()
Date: Mon, 13 Jan 2025 11:34:51 +0200 [thread overview]
Message-ID: <20250113093453.1932083-7-kirill.shutemov@linux.intel.com> (raw)
In-Reply-To: <20250113093453.1932083-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.
Instead of using folio_set_reclaim(), use folio_set_dropbehind() in
shrink_folio_list().
It is safe to leave PG_dropbehind on the folio if, for some reason
(bug?), the folio is not in a writeback state after ->writepage().
In these cases, the kernel had to clear PG_reclaim as it shared a page
flag bit with PG_readahead.
Also use PG_dropbehind instead PG_reclaim to detect I/O congestion.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
mm/vmscan.c | 30 ++++++++----------------------
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index d15f80333d6b..bb5ec22f97b5 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1140,7 +1140,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
* for immediate reclaim are making it to the end of
* the LRU a second time.
*/
- if (writeback && folio_test_reclaim(folio))
+ if (writeback && folio_test_dropbehind(folio))
stat->nr_congested += nr_pages;
/*
@@ -1149,7 +1149,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
*
* 1) If reclaim is encountering an excessive number
* of folios under writeback and this folio has both
- * the writeback and reclaim flags set, then it
+ * the writeback and dropbehind flags set, then it
* indicates that folios are being queued for I/O but
* are being recycled through the LRU before the I/O
* can complete. Waiting on the folio itself risks an
@@ -1174,7 +1174,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
* would probably show more reasons.
*
* 3) Legacy memcg encounters a folio that already has the
- * reclaim flag set. memcg does not have any dirty folio
+ * dropbehind flag set. memcg does not have any dirty folio
* throttling so we could easily OOM just because too many
* folios are in writeback and there is nothing else to
* reclaim. Wait for the writeback to complete.
@@ -1193,31 +1193,17 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
/* Case 1 above */
if (current_is_kswapd() &&
- folio_test_reclaim(folio) &&
+ folio_test_dropbehind(folio) &&
test_bit(PGDAT_WRITEBACK, &pgdat->flags)) {
stat->nr_immediate += nr_pages;
goto activate_locked;
/* Case 2 above */
} else if (writeback_throttling_sane(sc) ||
- !folio_test_reclaim(folio) ||
+ !folio_test_dropbehind(folio) ||
!may_enter_fs(folio, sc->gfp_mask) ||
(mapping && mapping_writeback_indeterminate(mapping))) {
- /*
- * This is slightly racy -
- * folio_end_writeback() might have
- * just cleared the reclaim flag, then
- * setting the reclaim flag here ends up
- * interpreted as the readahead flag - but
- * that does not matter enough to care.
- * What we do want is for this folio to
- * have the reclaim flag set next time
- * memcg reclaim reaches the tests above,
- * so it will then wait for writeback to
- * avoid OOM; and it's also appropriate
- * in global reclaim.
- */
- folio_set_reclaim(folio);
+ folio_set_dropbehind(folio);
stat->nr_writeback += nr_pages;
goto activate_locked;
@@ -1372,7 +1358,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
*/
if (folio_is_file_lru(folio) &&
(!current_is_kswapd() ||
- !folio_test_reclaim(folio) ||
+ !folio_test_dropbehind(folio) ||
!test_bit(PGDAT_DIRTY, &pgdat->flags))) {
/*
* Immediately reclaim when written back.
@@ -1382,7 +1368,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
*/
node_stat_mod_folio(folio, NR_VMSCAN_IMMEDIATE,
nr_pages);
- folio_set_reclaim(folio);
+ folio_set_dropbehind(folio);
goto activate_locked;
}
--
2.45.2
next prev parent reply other threads:[~2025-01-13 9:35 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-13 9:34 [PATCH 0/8] mm: Remove PG_reclaim Kirill A. Shutemov
2025-01-13 9:34 ` [PATCH 1/8] drm/i915/gem: Convert __shmem_writeback() to folios Kirill A. Shutemov
2025-01-13 10:05 ` David Hildenbrand
2025-01-13 9:34 ` [PATCH 2/8] drm/i915/gem: Use PG_dropbehind instead of PG_reclaim Kirill A. Shutemov
2025-01-13 10:06 ` David Hildenbrand
2025-01-13 9:34 ` [PATCH 3/8] mm/zswap: " Kirill A. Shutemov
2025-01-13 10:06 ` David Hildenbrand
2025-01-13 16:10 ` Yosry Ahmed
2025-01-13 9:34 ` [PATCH 4/8] mm/swap: " Kirill A. Shutemov
2025-01-13 10:07 ` David Hildenbrand
2025-01-13 16:17 ` Yosry Ahmed
2025-01-14 8:12 ` Kirill A. Shutemov
2025-01-14 18:02 ` Yosry Ahmed
2025-01-15 4:28 ` Yu Zhao
2025-01-15 4:31 ` Yu Zhao
2025-01-13 9:34 ` [PATCH 5/8] mm/vmscan: " Kirill A. Shutemov
2025-01-13 10:07 ` David Hildenbrand
2025-01-13 9:34 ` Kirill A. Shutemov [this message]
2025-01-13 10:08 ` [PATCH 6/8] mm/vmscan: Use PG_dropbehind instead of PG_reclaim in shrink_folio_list() David Hildenbrand
2025-01-13 9:34 ` [PATCH 7/8] mm/mglru: Check PG_dropcache instead of PG_reclaim in lru_gen_folio_seq() Kirill A. Shutemov
2025-01-13 10:09 ` David Hildenbrand
2025-01-13 9:34 ` [PATCH 8/8] mm: Remove PG_reclaim Kirill A. Shutemov
2025-01-13 10:11 ` David Hildenbrand
2025-01-13 15:28 ` Matthew Wilcox
2025-01-14 8:30 ` Kirill A. Shutemov
2025-01-14 17:01 ` Yu Zhao
2025-01-13 13:45 ` [PATCH 0/8] " Matthew Wilcox
2025-01-13 14:07 ` 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=20250113093453.1932083-7-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