From: Christoph Hellwig <hch@infradead.org>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: linux-mm@kvack.org, brauner@kernel.org, willy@infradead.org,
jack@suse.cz, hch@infradead.org, djwong@kernel.org,
linux-fsdevel@vger.kernel.org, kernel-team@meta.com
Subject: Re: [RFC PATCH v1 10/10] iomap: add granular dirty and writeback accounting
Date: Tue, 12 Aug 2025 01:15:11 -0700 [thread overview]
Message-ID: <aJr4D9ec7XG92G--@infradead.org> (raw)
In-Reply-To: <20250801002131.255068-11-joannelkoong@gmail.com>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index bcc6e0e5334e..626c3c8399cc 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -20,6 +20,8 @@ struct iomap_folio_state {
> spinlock_t state_lock;
> unsigned int read_bytes_pending;
> atomic_t write_bytes_pending;
> + /* number of pages being currently written back */
> + unsigned nr_pages_writeback;
This adds more sizse to the folio state. Shouldn't this be the same
as
DIV_ROUND_UP(write_bytes_pending, PAGE_SIZE)
anyway?
> + unsigned end_blk = min((unsigned)(i_size_read(inode) >> inode->i_blkbits),
> + i_blocks_per_folio(inode, folio));
Overly long line. Also not sure why the cast is needed to start with?
> + unsigned nblks = 0;
> +
> + while (start_blk < end_blk) {
> + if (ifs_block_is_dirty(folio, ifs, start_blk))
> + nblks++;
> + start_blk++;
> + }
We have this pattern open coded in a few places. Maybe factor it into a
helper first? And then maybe someone smart can actually make it use
find_first_bit/find_next_bit.
> +static bool iomap_granular_dirty_pages(struct folio *folio)
> +{
> + struct iomap_folio_state *ifs = folio->private;
> + struct inode *inode;
> + unsigned block_size;
> +
> + if (!ifs)
> + return false;
> +
> + inode = folio->mapping->host;
> + block_size = 1 << inode->i_blkbits;
> +
> + if (block_size >= PAGE_SIZE) {
> + WARN_ON(block_size & (PAGE_SIZE - 1));
> + return true;
> + }
> + return false;
Do we need the WARN_ON? Both the block and page size must be powers
of two, so I can't see how it would trigger. Also this can use the
i_blocksize helper.
I.e. just turn this into:
return i_blocksize(folio->mapping->host) >= PAGE_SIZE;
> +static bool iomap_dirty_folio_range(struct address_space *mapping, struct folio *folio,
Overly long line.
> + wpc->wbc->no_stats_accounting = true;
Who does the writeback accounting now? Maybe throw in a comment if
iomap is now doing something different than all the other writeback
code.
next prev parent reply other threads:[~2025-08-12 8:15 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 ` [RFC PATCH v1 06/10] mm: add __folio_clear_dirty_for_io() helper Joanne Koong
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 [this message]
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=aJr4D9ec7XG92G--@infradead.org \
--to=hch@infradead.org \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=joannelkoong@gmail.com \
--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.