All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joanne Koong <joannelkoong@gmail.com>
To: linux-mm@kvack.org, brauner@kernel.org
Cc: willy@infradead.org, jack@suse.cz, hch@infradead.org,
	djwong@kernel.org, linux-fsdevel@vger.kernel.org,
	kernel-team@meta.com
Subject: [RFC PATCH v1 06/10] mm: add __folio_clear_dirty_for_io() helper
Date: Thu, 31 Jul 2025 17:21:27 -0700	[thread overview]
Message-ID: <20250801002131.255068-7-joannelkoong@gmail.com> (raw)
In-Reply-To: <20250801002131.255068-1-joannelkoong@gmail.com>

Add __folio_clear_dirty_for_io() which takes in an arg for whether the
folio and wb stats should be updated as part of the call or not.

Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
---
 mm/page-writeback.c | 47 +++++++++++++++++++++++++++------------------
 1 file changed, 28 insertions(+), 19 deletions(-)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index a3805988f3ad..77a46bf8052f 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2927,21 +2927,7 @@ void __folio_cancel_dirty(struct folio *folio)
 }
 EXPORT_SYMBOL(__folio_cancel_dirty);
 
-/*
- * Clear a folio's dirty flag, while caring for dirty memory accounting.
- * Returns true if the folio was previously dirty.
- *
- * This is for preparing to put the folio under writeout.  We leave
- * the folio tagged as dirty in the xarray so that a concurrent
- * write-for-sync can discover it via a PAGECACHE_TAG_DIRTY walk.
- * The ->writepage implementation will run either folio_start_writeback()
- * or folio_mark_dirty(), at which stage we bring the folio's dirty flag
- * and xarray dirty tag back into sync.
- *
- * This incoherency between the folio's dirty flag and xarray tag is
- * unfortunate, but it only exists while the folio is locked.
- */
-bool folio_clear_dirty_for_io(struct folio *folio)
+static bool __folio_clear_dirty_for_io(struct folio *folio, bool update_stats)
 {
 	struct address_space *mapping = folio_mapping(folio);
 	bool ret = false;
@@ -2990,10 +2976,14 @@ bool folio_clear_dirty_for_io(struct folio *folio)
 		 */
 		wb = unlocked_inode_to_wb_begin(inode, &cookie);
 		if (folio_test_clear_dirty(folio)) {
-			long nr = folio_nr_pages(folio);
-			lruvec_stat_mod_folio(folio, NR_FILE_DIRTY, -nr);
-			zone_stat_mod_folio(folio, NR_ZONE_WRITE_PENDING, -nr);
-			wb_stat_mod(wb, WB_RECLAIMABLE, -nr);
+			if (update_stats) {
+				long nr = folio_nr_pages(folio);
+				lruvec_stat_mod_folio(folio, NR_FILE_DIRTY,
+						      -nr);
+				zone_stat_mod_folio(folio,
+						    NR_ZONE_WRITE_PENDING, -nr);
+				wb_stat_mod(wb, WB_RECLAIMABLE, -nr);
+			}
 			ret = true;
 		}
 		unlocked_inode_to_wb_end(inode, &cookie);
@@ -3001,6 +2991,25 @@ bool folio_clear_dirty_for_io(struct folio *folio)
 	}
 	return folio_test_clear_dirty(folio);
 }
+
+/*
+ * Clear a folio's dirty flag, while caring for dirty memory accounting.
+ * Returns true if the folio was previously dirty.
+ *
+ * This is for preparing to put the folio under writeout.  We leave
+ * the folio tagged as dirty in the xarray so that a concurrent
+ * write-for-sync can discover it via a PAGECACHE_TAG_DIRTY walk.
+ * The ->writepage implementation will run either folio_start_writeback()
+ * or folio_mark_dirty(), at which stage we bring the folio's dirty flag
+ * and xarray dirty tag back into sync.
+ *
+ * This incoherency between the folio's dirty flag and xarray tag is
+ * unfortunate, but it only exists while the folio is locked.
+ */
+bool folio_clear_dirty_for_io(struct folio *folio)
+{
+	return __folio_clear_dirty_for_io(folio, true);
+}
 EXPORT_SYMBOL(folio_clear_dirty_for_io);
 
 static void wb_inode_writeback_start(struct bdi_writeback *wb)
-- 
2.47.3



  parent reply	other threads:[~2025-08-01  0:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-01  0:21 [RFC PATCH v1 00/10] mm/iomap: add granular dirty and writeback accounting Joanne Koong
2025-08-01  0:21 ` [RFC PATCH v1 01/10] mm: pass number of pages to __folio_start_writeback() Joanne Koong
2025-08-01  0:21 ` [RFC PATCH v1 02/10] mm: pass number of pages to __folio_end_writeback() Joanne Koong
2025-08-01  0:21 ` [RFC PATCH v1 03/10] mm: add folio_end_writeback_pages() helper Joanne Koong
2025-08-12  8:03   ` Christoph Hellwig
2025-08-01  0:21 ` [RFC PATCH v1 04/10] mm: pass number of pages dirtied to __folio_mark_dirty() Joanne Koong
2025-08-01  0:21 ` [RFC PATCH v1 05/10] mm: add filemap_dirty_folio_pages() helper Joanne Koong
2025-08-01 17:07   ` Jan Kara
2025-08-01 21:47     ` Joanne Koong
2025-08-12  8:05   ` Christoph Hellwig
2025-08-01  0:21 ` Joanne Koong [this message]
2025-08-01  0:21 ` [RFC PATCH v1 07/10] mm: add no_stats_accounting bitfield to wbc Joanne Koong
2025-08-12  8:06   ` Christoph Hellwig
2025-08-01  0:21 ` [RFC PATCH v1 08/10] mm: refactor clearing dirty stats into helper function Joanne Koong
2025-08-04 16:26   ` Jeff Layton
2025-08-01  0:21 ` [RFC PATCH v1 09/10] mm: add clear_dirty_for_io_stats() helper Joanne Koong
2025-08-01  0:21 ` [RFC PATCH v1 10/10] iomap: add granular dirty and writeback accounting Joanne Koong
2025-08-12  8:15   ` Christoph Hellwig
2025-08-13  1:10     ` Joanne Koong
2025-08-13 22:03       ` Joanne Koong
2025-08-14 16:37   ` Darrick J. Wong
2025-08-15 18:38     ` Joanne Koong
2025-08-28  0:08       ` Joanne Koong
2025-08-29 23:02         ` Joanne Koong

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=20250801002131.255068-7-joannelkoong@gmail.com \
    --to=joannelkoong@gmail.com \
    --cc=brauner@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=kernel-team@meta.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.