linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/3] Cleanup some writeback codes
@ 2024-10-06 15:28 Tang Yizhou
  2024-10-06 15:28 ` [PATCH v2 1/3] mm/page-writeback.c: Rename BANDWIDTH_INTERVAL to BW_DIRTYLIMIT_INTERVAL Tang Yizhou
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Tang Yizhou @ 2024-10-06 15:28 UTC (permalink / raw)
  To: jack, hch, willy, akpm, chandan.babu
  Cc: linux-kernel, linux-fsdevel, linux-xfs, Tang Yizhou

From: Tang Yizhou <yizhou.tang@shopee.com>

v2:
PATCH #1: Rename BANDWIDTH_INTERVAL to BW_DIRTYLIMIT_INTERVAL and update
some comments.

PATCH #2: Pick up Jan's Reviewed-by tag.

PATCH #3: xfs_max_map_length() was written following the logic of
writeback_chunk_size().


Tang Yizhou (3):
  mm/page-writeback.c: Rename BANDWIDTH_INTERVAL to
    BW_DIRTYLIMIT_INTERVAL
  mm/page-writeback.c: Fix comment of wb_domain_writeout_add()
  xfs: Let the max iomap length be consistent with the writeback code

 fs/fs-writeback.c         |  5 ----
 fs/xfs/xfs_iomap.c        | 52 ++++++++++++++++++++++++---------------
 include/linux/writeback.h |  5 ++++
 mm/page-writeback.c       | 18 +++++++-------
 4 files changed, 46 insertions(+), 34 deletions(-)

-- 
2.25.1


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH v2 1/3] mm/page-writeback.c: Rename BANDWIDTH_INTERVAL to BW_DIRTYLIMIT_INTERVAL
  2024-10-06 15:28 [PATCH v2 0/3] Cleanup some writeback codes Tang Yizhou
@ 2024-10-06 15:28 ` Tang Yizhou
  2024-10-06 15:28 ` [PATCH v2 2/3] mm/page-writeback.c: Fix comment of wb_domain_writeout_add() Tang Yizhou
  2024-10-06 15:28 ` [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code Tang Yizhou
  2 siblings, 0 replies; 12+ messages in thread
From: Tang Yizhou @ 2024-10-06 15:28 UTC (permalink / raw)
  To: jack, hch, willy, akpm, chandan.babu
  Cc: linux-kernel, linux-fsdevel, linux-xfs, Tang Yizhou

From: Tang Yizhou <yizhou.tang@shopee.com>

The name of the BANDWIDTH_INTERVAL macro is misleading, as it is not
only used in the bandwidth update functions wb_update_bandwidth() and
__wb_update_bandwidth(), but also in the dirty limit update function
domain_update_dirty_limit().

Rename BANDWIDTH_INTERVAL to BW_DIRTYLIMIT_INTERVAL to make things clear.

This patche doesn't introduce any behavioral changes.

v2: Rename UPDATE_INTERVAL to BW_DIRTYLIMIT_INTERVAL.

Signed-off-by: Tang Yizhou <yizhou.tang@shopee.com>
---
 mm/page-writeback.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index fcd4c1439cb9..3af7bc078dc0 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -54,9 +54,9 @@
 #define DIRTY_POLL_THRESH	(128 >> (PAGE_SHIFT - 10))
 
 /*
- * Estimate write bandwidth at 200ms intervals.
+ * Estimate write bandwidth or update dirty limit at 200ms intervals.
  */
-#define BANDWIDTH_INTERVAL	max(HZ/5, 1)
+#define BW_DIRTYLIMIT_INTERVAL	max(HZ/5, 1)
 
 #define RATELIMIT_CALC_SHIFT	10
 
@@ -1331,11 +1331,11 @@ static void domain_update_dirty_limit(struct dirty_throttle_control *dtc,
 	/*
 	 * check locklessly first to optimize away locking for the most time
 	 */
-	if (time_before(now, dom->dirty_limit_tstamp + BANDWIDTH_INTERVAL))
+	if (time_before(now, dom->dirty_limit_tstamp + BW_DIRTYLIMIT_INTERVAL))
 		return;
 
 	spin_lock(&dom->lock);
-	if (time_after_eq(now, dom->dirty_limit_tstamp + BANDWIDTH_INTERVAL)) {
+	if (time_after_eq(now, dom->dirty_limit_tstamp + BW_DIRTYLIMIT_INTERVAL)) {
 		update_dirty_limit(dtc);
 		dom->dirty_limit_tstamp = now;
 	}
@@ -1928,7 +1928,7 @@ static int balance_dirty_pages(struct bdi_writeback *wb,
 		wb->dirty_exceeded = gdtc->dirty_exceeded ||
 				     (mdtc && mdtc->dirty_exceeded);
 		if (time_is_before_jiffies(READ_ONCE(wb->bw_time_stamp) +
-					   BANDWIDTH_INTERVAL))
+					   BW_DIRTYLIMIT_INTERVAL))
 			__wb_update_bandwidth(gdtc, mdtc, true);
 
 		/* throttle according to the chosen dtc */
@@ -2705,7 +2705,7 @@ int do_writepages(struct address_space *mapping, struct writeback_control *wbc)
 	 * writeback bandwidth is updated once in a while.
 	 */
 	if (time_is_before_jiffies(READ_ONCE(wb->bw_time_stamp) +
-				   BANDWIDTH_INTERVAL))
+				   BW_DIRTYLIMIT_INTERVAL))
 		wb_update_bandwidth(wb);
 	return ret;
 }
@@ -3057,14 +3057,14 @@ static void wb_inode_writeback_end(struct bdi_writeback *wb)
 	atomic_dec(&wb->writeback_inodes);
 	/*
 	 * Make sure estimate of writeback throughput gets updated after
-	 * writeback completed. We delay the update by BANDWIDTH_INTERVAL
+	 * writeback completed. We delay the update by BW_DIRTYLIMIT_INTERVAL
 	 * (which is the interval other bandwidth updates use for batching) so
 	 * that if multiple inodes end writeback at a similar time, they get
 	 * batched into one bandwidth update.
 	 */
 	spin_lock_irqsave(&wb->work_lock, flags);
 	if (test_bit(WB_registered, &wb->state))
-		queue_delayed_work(bdi_wq, &wb->bw_dwork, BANDWIDTH_INTERVAL);
+		queue_delayed_work(bdi_wq, &wb->bw_dwork, BW_DIRTYLIMIT_INTERVAL);
 	spin_unlock_irqrestore(&wb->work_lock, flags);
 }
 
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [PATCH v2 2/3] mm/page-writeback.c: Fix comment of wb_domain_writeout_add()
  2024-10-06 15:28 [PATCH v2 0/3] Cleanup some writeback codes Tang Yizhou
  2024-10-06 15:28 ` [PATCH v2 1/3] mm/page-writeback.c: Rename BANDWIDTH_INTERVAL to BW_DIRTYLIMIT_INTERVAL Tang Yizhou
@ 2024-10-06 15:28 ` Tang Yizhou
  2024-10-06 15:28 ` [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code Tang Yizhou
  2 siblings, 0 replies; 12+ messages in thread
From: Tang Yizhou @ 2024-10-06 15:28 UTC (permalink / raw)
  To: jack, hch, willy, akpm, chandan.babu
  Cc: linux-kernel, linux-fsdevel, linux-xfs, Tang Yizhou

From: Tang Yizhou <yizhou.tang@shopee.com>

__bdi_writeout_inc() has undergone multiple renamings, but the comment
within the function body have not been updated accordingly. Update it
to reflect the latest wb_domain_writeout_add().

Signed-off-by: Tang Yizhou <yizhou.tang@shopee.com>
Reviewed-by: Jan Kara <jack@suse.cz>
---
 mm/page-writeback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 3af7bc078dc0..68e48749c947 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -586,7 +586,7 @@ static void wb_domain_writeout_add(struct wb_domain *dom,
 	/* First event after period switching was turned off? */
 	if (unlikely(!dom->period_time)) {
 		/*
-		 * We can race with other __bdi_writeout_inc calls here but
+		 * We can race with other wb_domain_writeout_add calls here but
 		 * it does not cause any harm since the resulting time when
 		 * timer will fire and what is in writeout_period_time will be
 		 * roughly the same.
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code
  2024-10-06 15:28 [PATCH v2 0/3] Cleanup some writeback codes Tang Yizhou
  2024-10-06 15:28 ` [PATCH v2 1/3] mm/page-writeback.c: Rename BANDWIDTH_INTERVAL to BW_DIRTYLIMIT_INTERVAL Tang Yizhou
  2024-10-06 15:28 ` [PATCH v2 2/3] mm/page-writeback.c: Fix comment of wb_domain_writeout_add() Tang Yizhou
@ 2024-10-06 15:28 ` Tang Yizhou
  2024-10-06 16:30   ` Darrick J. Wong
                     ` (4 more replies)
  2 siblings, 5 replies; 12+ messages in thread
From: Tang Yizhou @ 2024-10-06 15:28 UTC (permalink / raw)
  To: jack, hch, willy, akpm, chandan.babu
  Cc: linux-kernel, linux-fsdevel, linux-xfs, Tang Yizhou

From: Tang Yizhou <yizhou.tang@shopee.com>

Since commit 1a12d8bd7b29 ("writeback: scale IO chunk size up to half
device bandwidth"), macro MAX_WRITEBACK_PAGES has been removed from the
writeback path. Therefore, the MAX_WRITEBACK_PAGES comments in
xfs_direct_write_iomap_begin() and xfs_buffered_write_iomap_begin() appear
outdated.

In addition, Christoph mentioned that the xfs iomap process should be
similar to writeback, so xfs_max_map_length() was written following the
logic of writeback_chunk_size().

v2: Thanks for Christoph's advice. Resync with the writeback code.

Signed-off-by: Tang Yizhou <yizhou.tang@shopee.com>
---
 fs/fs-writeback.c         |  5 ----
 fs/xfs/xfs_iomap.c        | 52 ++++++++++++++++++++++++---------------
 include/linux/writeback.h |  5 ++++
 3 files changed, 37 insertions(+), 25 deletions(-)

diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index d8bec3c1bb1f..31c72e207e1b 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -31,11 +31,6 @@
 #include <linux/memcontrol.h>
 #include "internal.h"
 
-/*
- * 4MB minimal write chunk size
- */
-#define MIN_WRITEBACK_PAGES	(4096UL >> (PAGE_SHIFT - 10))
-
 /*
  * Passed into wb_writeback(), essentially a subset of writeback_control
  */
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 1e11f48814c0..80f759fa9534 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -4,6 +4,8 @@
  * Copyright (c) 2016-2018 Christoph Hellwig.
  * All Rights Reserved.
  */
+#include <linux/writeback.h>
+
 #include "xfs.h"
 #include "xfs_fs.h"
 #include "xfs_shared.h"
@@ -744,6 +746,34 @@ xfs_ilock_for_iomap(
 	return 0;
 }
 
+/*
+ * We cap the maximum length we map to a sane size to keep the chunks
+ * of work done where somewhat symmetric with the work writeback does.
+ * This is a completely arbitrary number pulled out of thin air as a
+ * best guess for initial testing.
+ *
+ * Following the logic of writeback_chunk_size(), the length will be
+ * rounded to the nearest 4MB boundary.
+ *
+ * Note that the values needs to be less than 32-bits wide until the
+ * lower level functions are updated.
+ */
+static loff_t
+xfs_max_map_length(struct inode *inode, loff_t length)
+{
+	struct bdi_writeback *wb;
+	long pages;
+
+	spin_lock(&inode->i_lock);
+	wb = inode_to_wb(wb);
+	pages = min(wb->avg_write_bandwidth / 2,
+		    global_wb_domain.dirty_limit / DIRTY_SCOPE);
+	spin_unlock(&inode->i_lock);
+	pages = round_down(pages + MIN_WRITEBACK_PAGES, MIN_WRITEBACK_PAGES);
+
+	return min_t(loff_t, length, pages * PAGE_SIZE);
+}
+
 /*
  * Check that the imap we are going to return to the caller spans the entire
  * range that the caller requested for the IO.
@@ -878,16 +908,7 @@ xfs_direct_write_iomap_begin(
 	if (flags & (IOMAP_NOWAIT | IOMAP_OVERWRITE_ONLY))
 		goto out_unlock;
 
-	/*
-	 * We cap the maximum length we map to a sane size  to keep the chunks
-	 * of work done where somewhat symmetric with the work writeback does.
-	 * This is a completely arbitrary number pulled out of thin air as a
-	 * best guess for initial testing.
-	 *
-	 * Note that the values needs to be less than 32-bits wide until the
-	 * lower level functions are updated.
-	 */
-	length = min_t(loff_t, length, 1024 * PAGE_SIZE);
+	length = xfs_max_map_length(inode, length);
 	end_fsb = xfs_iomap_end_fsb(mp, offset, length);
 
 	if (offset + length > XFS_ISIZE(ip))
@@ -1096,16 +1117,7 @@ xfs_buffered_write_iomap_begin(
 		allocfork = XFS_COW_FORK;
 		end_fsb = imap.br_startoff + imap.br_blockcount;
 	} else {
-		/*
-		 * We cap the maximum length we map here to MAX_WRITEBACK_PAGES
-		 * pages to keep the chunks of work done where somewhat
-		 * symmetric with the work writeback does.  This is a completely
-		 * arbitrary number pulled out of thin air.
-		 *
-		 * Note that the values needs to be less than 32-bits wide until
-		 * the lower level functions are updated.
-		 */
-		count = min_t(loff_t, count, 1024 * PAGE_SIZE);
+		count = xfs_max_map_length(inode, count);
 		end_fsb = xfs_iomap_end_fsb(mp, offset, count);
 
 		if (xfs_is_always_cow_inode(ip))
diff --git a/include/linux/writeback.h b/include/linux/writeback.h
index d6db822e4bb3..657bc4dd22d0 100644
--- a/include/linux/writeback.h
+++ b/include/linux/writeback.h
@@ -17,6 +17,11 @@ struct bio;
 
 DECLARE_PER_CPU(int, dirty_throttle_leaks);
 
+/*
+ * 4MB minimal write chunk size
+ */
+#define MIN_WRITEBACK_PAGES	(4096UL >> (PAGE_SHIFT - 10))
+
 /*
  * The global dirty threshold is normally equal to the global dirty limit,
  * except when the system suddenly allocates a lot of anonymous memory and
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code
  2024-10-06 15:28 ` [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code Tang Yizhou
@ 2024-10-06 16:30   ` Darrick J. Wong
  2024-10-07  5:36     ` Tang Yizhou
  2024-10-07 16:36   ` Jan Kara
                     ` (3 subsequent siblings)
  4 siblings, 1 reply; 12+ messages in thread
From: Darrick J. Wong @ 2024-10-06 16:30 UTC (permalink / raw)
  To: Tang Yizhou
  Cc: jack, hch, willy, akpm, chandan.babu, linux-kernel, linux-fsdevel,
	linux-xfs

On Sun, Oct 06, 2024 at 11:28:49PM +0800, Tang Yizhou wrote:
> From: Tang Yizhou <yizhou.tang@shopee.com>
> 
> Since commit 1a12d8bd7b29 ("writeback: scale IO chunk size up to half
> device bandwidth"), macro MAX_WRITEBACK_PAGES has been removed from the
> writeback path. Therefore, the MAX_WRITEBACK_PAGES comments in
> xfs_direct_write_iomap_begin() and xfs_buffered_write_iomap_begin() appear
> outdated.
> 
> In addition, Christoph mentioned that the xfs iomap process should be
> similar to writeback, so xfs_max_map_length() was written following the
> logic of writeback_chunk_size().
> 
> v2: Thanks for Christoph's advice. Resync with the writeback code.
> 
> Signed-off-by: Tang Yizhou <yizhou.tang@shopee.com>
> ---
>  fs/fs-writeback.c         |  5 ----
>  fs/xfs/xfs_iomap.c        | 52 ++++++++++++++++++++++++---------------
>  include/linux/writeback.h |  5 ++++
>  3 files changed, 37 insertions(+), 25 deletions(-)
> 
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index d8bec3c1bb1f..31c72e207e1b 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -31,11 +31,6 @@
>  #include <linux/memcontrol.h>
>  #include "internal.h"
>  
> -/*
> - * 4MB minimal write chunk size
> - */
> -#define MIN_WRITEBACK_PAGES	(4096UL >> (PAGE_SHIFT - 10))
> -
>  /*
>   * Passed into wb_writeback(), essentially a subset of writeback_control
>   */
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 1e11f48814c0..80f759fa9534 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -4,6 +4,8 @@
>   * Copyright (c) 2016-2018 Christoph Hellwig.
>   * All Rights Reserved.
>   */
> +#include <linux/writeback.h>
> +
>  #include "xfs.h"
>  #include "xfs_fs.h"
>  #include "xfs_shared.h"
> @@ -744,6 +746,34 @@ xfs_ilock_for_iomap(
>  	return 0;
>  }
>  
> +/*
> + * We cap the maximum length we map to a sane size to keep the chunks
> + * of work done where somewhat symmetric with the work writeback does.
> + * This is a completely arbitrary number pulled out of thin air as a
> + * best guess for initial testing.
> + *
> + * Following the logic of writeback_chunk_size(), the length will be
> + * rounded to the nearest 4MB boundary.
> + *
> + * Note that the values needs to be less than 32-bits wide until the
> + * lower level functions are updated.
> + */
> +static loff_t
> +xfs_max_map_length(struct inode *inode, loff_t length)
> +{
> +	struct bdi_writeback *wb;
> +	long pages;
> +
> +	spin_lock(&inode->i_lock);

Why's it necessary to hold a spinlock?  AFAICT writeback_chunk_size
doesn't hold it.

> +	wb = inode_to_wb(wb);

Hmm, it looks like you're trying to cap writes based on storage device
bandwidth instead of a static limit.  That could be nifty, but does this
work for a file on the realtime device?  Or any device that isn't the
super_block s_bdi?

> +	pages = min(wb->avg_write_bandwidth / 2,
> +		    global_wb_domain.dirty_limit / DIRTY_SCOPE);
> +	spin_unlock(&inode->i_lock);
> +	pages = round_down(pages + MIN_WRITEBACK_PAGES, MIN_WRITEBACK_PAGES);
> +
> +	return min_t(loff_t, length, pages * PAGE_SIZE);
> +}

There's nothing in here that's xfs-specific, shouldn't this be a
fs-writeback.c function for any other filesystem that might want to cap
the size of a write?

--D

> +
>  /*
>   * Check that the imap we are going to return to the caller spans the entire
>   * range that the caller requested for the IO.
> @@ -878,16 +908,7 @@ xfs_direct_write_iomap_begin(
>  	if (flags & (IOMAP_NOWAIT | IOMAP_OVERWRITE_ONLY))
>  		goto out_unlock;
>  
> -	/*
> -	 * We cap the maximum length we map to a sane size  to keep the chunks
> -	 * of work done where somewhat symmetric with the work writeback does.
> -	 * This is a completely arbitrary number pulled out of thin air as a
> -	 * best guess for initial testing.
> -	 *
> -	 * Note that the values needs to be less than 32-bits wide until the
> -	 * lower level functions are updated.
> -	 */
> -	length = min_t(loff_t, length, 1024 * PAGE_SIZE);
> +	length = xfs_max_map_length(inode, length);
>  	end_fsb = xfs_iomap_end_fsb(mp, offset, length);
>  
>  	if (offset + length > XFS_ISIZE(ip))
> @@ -1096,16 +1117,7 @@ xfs_buffered_write_iomap_begin(
>  		allocfork = XFS_COW_FORK;
>  		end_fsb = imap.br_startoff + imap.br_blockcount;
>  	} else {
> -		/*
> -		 * We cap the maximum length we map here to MAX_WRITEBACK_PAGES
> -		 * pages to keep the chunks of work done where somewhat
> -		 * symmetric with the work writeback does.  This is a completely
> -		 * arbitrary number pulled out of thin air.
> -		 *
> -		 * Note that the values needs to be less than 32-bits wide until
> -		 * the lower level functions are updated.
> -		 */
> -		count = min_t(loff_t, count, 1024 * PAGE_SIZE);
> +		count = xfs_max_map_length(inode, count);
>  		end_fsb = xfs_iomap_end_fsb(mp, offset, count);
>  
>  		if (xfs_is_always_cow_inode(ip))
> diff --git a/include/linux/writeback.h b/include/linux/writeback.h
> index d6db822e4bb3..657bc4dd22d0 100644
> --- a/include/linux/writeback.h
> +++ b/include/linux/writeback.h
> @@ -17,6 +17,11 @@ struct bio;
>  
>  DECLARE_PER_CPU(int, dirty_throttle_leaks);
>  
> +/*
> + * 4MB minimal write chunk size
> + */
> +#define MIN_WRITEBACK_PAGES	(4096UL >> (PAGE_SHIFT - 10))
> +
>  /*
>   * The global dirty threshold is normally equal to the global dirty limit,
>   * except when the system suddenly allocates a lot of anonymous memory and
> -- 
> 2.25.1
> 
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code
  2024-10-06 16:30   ` Darrick J. Wong
@ 2024-10-07  5:36     ` Tang Yizhou
  0 siblings, 0 replies; 12+ messages in thread
From: Tang Yizhou @ 2024-10-07  5:36 UTC (permalink / raw)
  To: Darrick J. Wong
  Cc: jack, hch, willy, akpm, chandan.babu, linux-kernel, linux-fsdevel,
	linux-xfs

On Mon, Oct 7, 2024 at 12:30 AM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Sun, Oct 06, 2024 at 11:28:49PM +0800, Tang Yizhou wrote:
> > From: Tang Yizhou <yizhou.tang@shopee.com>
> >
> > Since commit 1a12d8bd7b29 ("writeback: scale IO chunk size up to half
> > device bandwidth"), macro MAX_WRITEBACK_PAGES has been removed from the
> > writeback path. Therefore, the MAX_WRITEBACK_PAGES comments in
> > xfs_direct_write_iomap_begin() and xfs_buffered_write_iomap_begin() appear
> > outdated.
> >
> > In addition, Christoph mentioned that the xfs iomap process should be
> > similar to writeback, so xfs_max_map_length() was written following the
> > logic of writeback_chunk_size().
> >
> > v2: Thanks for Christoph's advice. Resync with the writeback code.
> >
> > Signed-off-by: Tang Yizhou <yizhou.tang@shopee.com>
> > ---
> >  fs/fs-writeback.c         |  5 ----
> >  fs/xfs/xfs_iomap.c        | 52 ++++++++++++++++++++++++---------------
> >  include/linux/writeback.h |  5 ++++
> >  3 files changed, 37 insertions(+), 25 deletions(-)
> >
> > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> > index d8bec3c1bb1f..31c72e207e1b 100644
> > --- a/fs/fs-writeback.c
> > +++ b/fs/fs-writeback.c
> > @@ -31,11 +31,6 @@
> >  #include <linux/memcontrol.h>
> >  #include "internal.h"
> >
> > -/*
> > - * 4MB minimal write chunk size
> > - */
> > -#define MIN_WRITEBACK_PAGES  (4096UL >> (PAGE_SHIFT - 10))
> > -
> >  /*
> >   * Passed into wb_writeback(), essentially a subset of writeback_control
> >   */
> > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> > index 1e11f48814c0..80f759fa9534 100644
> > --- a/fs/xfs/xfs_iomap.c
> > +++ b/fs/xfs/xfs_iomap.c
> > @@ -4,6 +4,8 @@
> >   * Copyright (c) 2016-2018 Christoph Hellwig.
> >   * All Rights Reserved.
> >   */
> > +#include <linux/writeback.h>
> > +
> >  #include "xfs.h"
> >  #include "xfs_fs.h"
> >  #include "xfs_shared.h"
> > @@ -744,6 +746,34 @@ xfs_ilock_for_iomap(
> >       return 0;
> >  }
> >
> > +/*
> > + * We cap the maximum length we map to a sane size to keep the chunks
> > + * of work done where somewhat symmetric with the work writeback does.
> > + * This is a completely arbitrary number pulled out of thin air as a
> > + * best guess for initial testing.
> > + *
> > + * Following the logic of writeback_chunk_size(), the length will be
> > + * rounded to the nearest 4MB boundary.
> > + *
> > + * Note that the values needs to be less than 32-bits wide until the
> > + * lower level functions are updated.
> > + */
> > +static loff_t
> > +xfs_max_map_length(struct inode *inode, loff_t length)
> > +{
> > +     struct bdi_writeback *wb;
> > +     long pages;
> > +
> > +     spin_lock(&inode->i_lock);
>
> Why's it necessary to hold a spinlock?  AFAICT writeback_chunk_size
> doesn't hold it.
>

Since the caller of writeback_chunk_size(), writeback_sb_inodes(), already holds
wb->list_lock. According to the function comments of inode_to_wb(),
holding either
inode->i_lock or the associated wb's list_lock is acceptable.

> > +     wb = inode_to_wb(wb);
>
> Hmm, it looks like you're trying to cap writes based on storage device
> bandwidth instead of a static limit.  That could be nifty, but does this
> work for a file on the realtime device?  Or any device that isn't the
> super_block s_bdi?
>

I'm not very sure. Considering that the implementation of
writeback_chunk_size() in
the writeback path has remained unchanged for many years, I believe
its logic works
well in various scenarios.

> > +     pages = min(wb->avg_write_bandwidth / 2,
> > +                 global_wb_domain.dirty_limit / DIRTY_SCOPE);
> > +     spin_unlock(&inode->i_lock);
> > +     pages = round_down(pages + MIN_WRITEBACK_PAGES, MIN_WRITEBACK_PAGES);
> > +
> > +     return min_t(loff_t, length, pages * PAGE_SIZE);
> > +}
>
> There's nothing in here that's xfs-specific, shouldn't this be a
> fs-writeback.c function for any other filesystem that might want to cap
> the size of a write?
>

These logics are indeed not xfs-specific. However, I checked the
related implementations
in ext4 and btrfs, and it seems that these file systems do not require
similar logic to cap
the size. If we move the implementation of this function to
fs-writeback.c, the only user
would still be xfs.

Additionally, there are some differences in the implementation details
between this function
and writeback_chunk_size(), so it doesn't seem convenient to reuse the code.

Yi

> --D
>
> > +
> >  /*
> >   * Check that the imap we are going to return to the caller spans the entire
> >   * range that the caller requested for the IO.
> > @@ -878,16 +908,7 @@ xfs_direct_write_iomap_begin(
> >       if (flags & (IOMAP_NOWAIT | IOMAP_OVERWRITE_ONLY))
> >               goto out_unlock;
> >
> > -     /*
> > -      * We cap the maximum length we map to a sane size  to keep the chunks
> > -      * of work done where somewhat symmetric with the work writeback does.
> > -      * This is a completely arbitrary number pulled out of thin air as a
> > -      * best guess for initial testing.
> > -      *
> > -      * Note that the values needs to be less than 32-bits wide until the
> > -      * lower level functions are updated.
> > -      */
> > -     length = min_t(loff_t, length, 1024 * PAGE_SIZE);
> > +     length = xfs_max_map_length(inode, length);
> >       end_fsb = xfs_iomap_end_fsb(mp, offset, length);
> >
> >       if (offset + length > XFS_ISIZE(ip))
> > @@ -1096,16 +1117,7 @@ xfs_buffered_write_iomap_begin(
> >               allocfork = XFS_COW_FORK;
> >               end_fsb = imap.br_startoff + imap.br_blockcount;
> >       } else {
> > -             /*
> > -              * We cap the maximum length we map here to MAX_WRITEBACK_PAGES
> > -              * pages to keep the chunks of work done where somewhat
> > -              * symmetric with the work writeback does.  This is a completely
> > -              * arbitrary number pulled out of thin air.
> > -              *
> > -              * Note that the values needs to be less than 32-bits wide until
> > -              * the lower level functions are updated.
> > -              */
> > -             count = min_t(loff_t, count, 1024 * PAGE_SIZE);
> > +             count = xfs_max_map_length(inode, count);
> >               end_fsb = xfs_iomap_end_fsb(mp, offset, count);
> >
> >               if (xfs_is_always_cow_inode(ip))
> > diff --git a/include/linux/writeback.h b/include/linux/writeback.h
> > index d6db822e4bb3..657bc4dd22d0 100644
> > --- a/include/linux/writeback.h
> > +++ b/include/linux/writeback.h
> > @@ -17,6 +17,11 @@ struct bio;
> >
> >  DECLARE_PER_CPU(int, dirty_throttle_leaks);
> >
> > +/*
> > + * 4MB minimal write chunk size
> > + */
> > +#define MIN_WRITEBACK_PAGES  (4096UL >> (PAGE_SHIFT - 10))
> > +
> >  /*
> >   * The global dirty threshold is normally equal to the global dirty limit,
> >   * except when the system suddenly allocates a lot of anonymous memory and
> > --
> > 2.25.1
> >
> >

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code
  2024-10-06 15:28 ` [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code Tang Yizhou
  2024-10-06 16:30   ` Darrick J. Wong
@ 2024-10-07 16:36   ` Jan Kara
  2024-10-07 17:52     ` Darrick J. Wong
  2024-10-07 21:36   ` Dave Chinner
                     ` (2 subsequent siblings)
  4 siblings, 1 reply; 12+ messages in thread
From: Jan Kara @ 2024-10-07 16:36 UTC (permalink / raw)
  To: Tang Yizhou
  Cc: jack, hch, willy, akpm, chandan.babu, linux-kernel, linux-fsdevel,
	linux-xfs

On Sun 06-10-24 23:28:49, Tang Yizhou wrote:
> From: Tang Yizhou <yizhou.tang@shopee.com>
> 
> Since commit 1a12d8bd7b29 ("writeback: scale IO chunk size up to half
> device bandwidth"), macro MAX_WRITEBACK_PAGES has been removed from the
> writeback path. Therefore, the MAX_WRITEBACK_PAGES comments in
> xfs_direct_write_iomap_begin() and xfs_buffered_write_iomap_begin() appear
> outdated.
> 
> In addition, Christoph mentioned that the xfs iomap process should be
> similar to writeback, so xfs_max_map_length() was written following the
> logic of writeback_chunk_size().

Well, I'd defer to XFS maintainers here but at least to me it does not make
a huge amount of sense to scale mapping size with the device writeback
throughput. E.g. if the device writeback throughput is low, it does not
mean that it is good to perform current write(2) in small chunks...

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code
  2024-10-07 16:36   ` Jan Kara
@ 2024-10-07 17:52     ` Darrick J. Wong
  0 siblings, 0 replies; 12+ messages in thread
From: Darrick J. Wong @ 2024-10-07 17:52 UTC (permalink / raw)
  To: Jan Kara
  Cc: Tang Yizhou, hch, willy, akpm, chandan.babu, linux-kernel,
	linux-fsdevel, linux-xfs

On Mon, Oct 07, 2024 at 06:36:09PM +0200, Jan Kara wrote:
> On Sun 06-10-24 23:28:49, Tang Yizhou wrote:
> > From: Tang Yizhou <yizhou.tang@shopee.com>
> > 
> > Since commit 1a12d8bd7b29 ("writeback: scale IO chunk size up to half
> > device bandwidth"), macro MAX_WRITEBACK_PAGES has been removed from the
> > writeback path. Therefore, the MAX_WRITEBACK_PAGES comments in
> > xfs_direct_write_iomap_begin() and xfs_buffered_write_iomap_begin() appear
> > outdated.
> > 
> > In addition, Christoph mentioned that the xfs iomap process should be
> > similar to writeback, so xfs_max_map_length() was written following the
> > logic of writeback_chunk_size().
> 
> Well, I'd defer to XFS maintainers here but at least to me it does not make
> a huge amount of sense to scale mapping size with the device writeback
> throughput. E.g. if the device writeback throughput is low, it does not
> mean that it is good to perform current write(2) in small chunks...

Yeah, I was wondering if it still makes sense to throttle incoming
writes given that iomap will just call back for more mappings anyway.

--D

> 								Honza
> 
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code
  2024-10-06 15:28 ` [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code Tang Yizhou
  2024-10-06 16:30   ` Darrick J. Wong
  2024-10-07 16:36   ` Jan Kara
@ 2024-10-07 21:36   ` Dave Chinner
  2024-10-08  6:35     ` Christoph Hellwig
  2024-10-09  7:24   ` kernel test robot
  2024-10-09  8:26   ` kernel test robot
  4 siblings, 1 reply; 12+ messages in thread
From: Dave Chinner @ 2024-10-07 21:36 UTC (permalink / raw)
  To: Tang Yizhou
  Cc: jack, hch, willy, akpm, chandan.babu, linux-kernel, linux-fsdevel,
	linux-xfs

On Sun, Oct 06, 2024 at 11:28:49PM +0800, Tang Yizhou wrote:
> From: Tang Yizhou <yizhou.tang@shopee.com>
> 
> Since commit 1a12d8bd7b29 ("writeback: scale IO chunk size up to half
> device bandwidth"), macro MAX_WRITEBACK_PAGES has been removed from the
> writeback path. Therefore, the MAX_WRITEBACK_PAGES comments in
> xfs_direct_write_iomap_begin() and xfs_buffered_write_iomap_begin() appear
> outdated.
> 
> In addition, Christoph mentioned that the xfs iomap process should be
> similar to writeback, so xfs_max_map_length() was written following the
> logic of writeback_chunk_size().
> 
> v2: Thanks for Christoph's advice. Resync with the writeback code.
> 
> Signed-off-by: Tang Yizhou <yizhou.tang@shopee.com>
> ---
>  fs/fs-writeback.c         |  5 ----
>  fs/xfs/xfs_iomap.c        | 52 ++++++++++++++++++++++++---------------
>  include/linux/writeback.h |  5 ++++
>  3 files changed, 37 insertions(+), 25 deletions(-)
> 
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index d8bec3c1bb1f..31c72e207e1b 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -31,11 +31,6 @@
>  #include <linux/memcontrol.h>
>  #include "internal.h"
>  
> -/*
> - * 4MB minimal write chunk size
> - */
> -#define MIN_WRITEBACK_PAGES	(4096UL >> (PAGE_SHIFT - 10))
> -
>  /*
>   * Passed into wb_writeback(), essentially a subset of writeback_control
>   */
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 1e11f48814c0..80f759fa9534 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -4,6 +4,8 @@
>   * Copyright (c) 2016-2018 Christoph Hellwig.
>   * All Rights Reserved.
>   */
> +#include <linux/writeback.h>
> +
>  #include "xfs.h"
>  #include "xfs_fs.h"
>  #include "xfs_shared.h"
> @@ -744,6 +746,34 @@ xfs_ilock_for_iomap(
>  	return 0;
>  }
>  
> +/*
> + * We cap the maximum length we map to a sane size to keep the chunks
> + * of work done where somewhat symmetric with the work writeback does.
> + * This is a completely arbitrary number pulled out of thin air as a
> + * best guess for initial testing.
> + *
> + * Following the logic of writeback_chunk_size(), the length will be
> + * rounded to the nearest 4MB boundary.
> + *
> + * Note that the values needs to be less than 32-bits wide until the
> + * lower level functions are updated.
> + */
> +static loff_t
> +xfs_max_map_length(struct inode *inode, loff_t length)
> +{
> +	struct bdi_writeback *wb;
> +	long pages;
> +
> +	spin_lock(&inode->i_lock);
> +	wb = inode_to_wb(wb);
> +	pages = min(wb->avg_write_bandwidth / 2,
> +		    global_wb_domain.dirty_limit / DIRTY_SCOPE);
> +	spin_unlock(&inode->i_lock);
> +	pages = round_down(pages + MIN_WRITEBACK_PAGES, MIN_WRITEBACK_PAGES);
> +
> +	return min_t(loff_t, length, pages * PAGE_SIZE);
> +}

I think this map size limiting is completely unnecessary for
buffered writeback - buffered writes are throttled against writeback
by balance_dirty_pages(), not by extent allocation size. The size of
the delayed allocation or the overwrite map is largely irrelevant -
we're going to map the entire range during a write, do it just
doesn't matter what size the mapping is...

>  /*
>   * Check that the imap we are going to return to the caller spans the entire
>   * range that the caller requested for the IO.
> @@ -878,16 +908,7 @@ xfs_direct_write_iomap_begin(
>  	if (flags & (IOMAP_NOWAIT | IOMAP_OVERWRITE_ONLY))
>  		goto out_unlock;
>  
> -	/*
> -	 * We cap the maximum length we map to a sane size  to keep the chunks
> -	 * of work done where somewhat symmetric with the work writeback does.
> -	 * This is a completely arbitrary number pulled out of thin air as a
> -	 * best guess for initial testing.
> -	 *
> -	 * Note that the values needs to be less than 32-bits wide until the
> -	 * lower level functions are updated.
> -	 */
> -	length = min_t(loff_t, length, 1024 * PAGE_SIZE);
> +	length = xfs_max_map_length(inode, length);
>  	end_fsb = xfs_iomap_end_fsb(mp, offset, length);

And I'd just remove this altogether from the direct IO path. The DIO
code will chain as many bios as it takes to issue Io over the entire
mapping that is returned. Given that buffered writeback has done
arbitrarily large writeback for quite some time now, I don't think
there is any need to limit the bio chain lengths in the DIO path
like this anymore, either.

i.e. I'd be looking at removing the "arbitrary size limit" code, not
making it more complex.

-Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code
  2024-10-07 21:36   ` Dave Chinner
@ 2024-10-08  6:35     ` Christoph Hellwig
  0 siblings, 0 replies; 12+ messages in thread
From: Christoph Hellwig @ 2024-10-08  6:35 UTC (permalink / raw)
  To: Dave Chinner
  Cc: Tang Yizhou, jack, hch, willy, akpm, chandan.babu, linux-kernel,
	linux-fsdevel, linux-xfs

On Tue, Oct 08, 2024 at 08:36:02AM +1100, Dave Chinner wrote:
> I think this map size limiting is completely unnecessary for
> buffered writeback - buffered writes are throttled against writeback
> by balance_dirty_pages(), not by extent allocation size. The size of
> the delayed allocation or the overwrite map is largely irrelevant -
> we're going to map the entire range during a write, do it just
> doesn't matter what size the mapping is...

Yes.  This goes back all the way to your original iomap prototype,
but even back then balance_dirty_pages should have done all the
work.  


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code
  2024-10-06 15:28 ` [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code Tang Yizhou
                     ` (2 preceding siblings ...)
  2024-10-07 21:36   ` Dave Chinner
@ 2024-10-09  7:24   ` kernel test robot
  2024-10-09  8:26   ` kernel test robot
  4 siblings, 0 replies; 12+ messages in thread
From: kernel test robot @ 2024-10-09  7:24 UTC (permalink / raw)
  To: Tang Yizhou, jack, hch, willy, akpm, chandan.babu
  Cc: llvm, oe-kbuild-all, linux-kernel, linux-fsdevel, linux-xfs,
	Tang Yizhou

Hi Tang,

kernel test robot noticed the following build errors:

[auto build test ERROR on akpm-mm/mm-everything]
[also build test ERROR on brauner-vfs/vfs.all xfs-linux/for-next linus/master v6.12-rc2 next-20241008]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Tang-Yizhou/mm-page-writeback-c-Rename-BANDWIDTH_INTERVAL-to-BW_DIRTYLIMIT_INTERVAL/20241006-225445
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/20241006152849.247152-4-yizhou.tang%40shopee.com
patch subject: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20241009/202410091559.uWiy0Oj0-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241009/202410091559.uWiy0Oj0-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202410091559.uWiy0Oj0-lkp@intel.com/

All errors (new ones prefixed by >>):

>> fs/xfs/xfs_iomap.c:768:7: error: call to undeclared function 'inode_to_wb'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
     768 |         wb = inode_to_wb(wb);
         |              ^
>> fs/xfs/xfs_iomap.c:768:5: error: incompatible integer to pointer conversion assigning to 'struct bdi_writeback *' from 'int' [-Wint-conversion]
     768 |         wb = inode_to_wb(wb);
         |            ^ ~~~~~~~~~~~~~~~
   2 errors generated.


vim +/inode_to_wb +768 fs/xfs/xfs_iomap.c

   748	
   749	/*
   750	 * We cap the maximum length we map to a sane size to keep the chunks
   751	 * of work done where somewhat symmetric with the work writeback does.
   752	 * This is a completely arbitrary number pulled out of thin air as a
   753	 * best guess for initial testing.
   754	 *
   755	 * Following the logic of writeback_chunk_size(), the length will be
   756	 * rounded to the nearest 4MB boundary.
   757	 *
   758	 * Note that the values needs to be less than 32-bits wide until the
   759	 * lower level functions are updated.
   760	 */
   761	static loff_t
   762	xfs_max_map_length(struct inode *inode, loff_t length)
   763	{
   764		struct bdi_writeback *wb;
   765		long pages;
   766	
   767		spin_lock(&inode->i_lock);
 > 768		wb = inode_to_wb(wb);
   769		pages = min(wb->avg_write_bandwidth / 2,
   770			    global_wb_domain.dirty_limit / DIRTY_SCOPE);
   771		spin_unlock(&inode->i_lock);
   772		pages = round_down(pages + MIN_WRITEBACK_PAGES, MIN_WRITEBACK_PAGES);
   773	
   774		return min_t(loff_t, length, pages * PAGE_SIZE);
   775	}
   776	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code
  2024-10-06 15:28 ` [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code Tang Yizhou
                     ` (3 preceding siblings ...)
  2024-10-09  7:24   ` kernel test robot
@ 2024-10-09  8:26   ` kernel test robot
  4 siblings, 0 replies; 12+ messages in thread
From: kernel test robot @ 2024-10-09  8:26 UTC (permalink / raw)
  To: Tang Yizhou, jack, hch, willy, akpm, chandan.babu
  Cc: oe-kbuild-all, linux-kernel, linux-fsdevel, linux-xfs,
	Tang Yizhou

Hi Tang,

kernel test robot noticed the following build errors:

[auto build test ERROR on akpm-mm/mm-everything]
[also build test ERROR on brauner-vfs/vfs.all xfs-linux/for-next linus/master v6.12-rc2 next-20241008]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Tang-Yizhou/mm-page-writeback-c-Rename-BANDWIDTH_INTERVAL-to-BW_DIRTYLIMIT_INTERVAL/20241006-225445
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/20241006152849.247152-4-yizhou.tang%40shopee.com
patch subject: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code
config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20241009/202410091647.eyo14ayt-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 14.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241009/202410091647.eyo14ayt-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202410091647.eyo14ayt-lkp@intel.com/

All errors (new ones prefixed by >>):

   fs/xfs/xfs_iomap.c: In function 'xfs_max_map_length':
   fs/xfs/xfs_iomap.c:768:14: error: implicit declaration of function 'inode_to_wb' [-Wimplicit-function-declaration]
     768 |         wb = inode_to_wb(wb);
         |              ^~~~~~~~~~~
>> fs/xfs/xfs_iomap.c:768:12: error: assignment to 'struct bdi_writeback *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
     768 |         wb = inode_to_wb(wb);
         |            ^

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for GET_FREE_REGION
   Depends on [n]: SPARSEMEM [=n]
   Selected by [m]:
   - RESOURCE_KUNIT_TEST [=m] && RUNTIME_TESTING_MENU [=y] && KUNIT [=m]


vim +768 fs/xfs/xfs_iomap.c

   748	
   749	/*
   750	 * We cap the maximum length we map to a sane size to keep the chunks
   751	 * of work done where somewhat symmetric with the work writeback does.
   752	 * This is a completely arbitrary number pulled out of thin air as a
   753	 * best guess for initial testing.
   754	 *
   755	 * Following the logic of writeback_chunk_size(), the length will be
   756	 * rounded to the nearest 4MB boundary.
   757	 *
   758	 * Note that the values needs to be less than 32-bits wide until the
   759	 * lower level functions are updated.
   760	 */
   761	static loff_t
   762	xfs_max_map_length(struct inode *inode, loff_t length)
   763	{
   764		struct bdi_writeback *wb;
   765		long pages;
   766	
   767		spin_lock(&inode->i_lock);
 > 768		wb = inode_to_wb(wb);
   769		pages = min(wb->avg_write_bandwidth / 2,
   770			    global_wb_domain.dirty_limit / DIRTY_SCOPE);
   771		spin_unlock(&inode->i_lock);
   772		pages = round_down(pages + MIN_WRITEBACK_PAGES, MIN_WRITEBACK_PAGES);
   773	
   774		return min_t(loff_t, length, pages * PAGE_SIZE);
   775	}
   776	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2024-10-09  8:27 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-06 15:28 [PATCH v2 0/3] Cleanup some writeback codes Tang Yizhou
2024-10-06 15:28 ` [PATCH v2 1/3] mm/page-writeback.c: Rename BANDWIDTH_INTERVAL to BW_DIRTYLIMIT_INTERVAL Tang Yizhou
2024-10-06 15:28 ` [PATCH v2 2/3] mm/page-writeback.c: Fix comment of wb_domain_writeout_add() Tang Yizhou
2024-10-06 15:28 ` [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code Tang Yizhou
2024-10-06 16:30   ` Darrick J. Wong
2024-10-07  5:36     ` Tang Yizhou
2024-10-07 16:36   ` Jan Kara
2024-10-07 17:52     ` Darrick J. Wong
2024-10-07 21:36   ` Dave Chinner
2024-10-08  6:35     ` Christoph Hellwig
2024-10-09  7:24   ` kernel test robot
2024-10-09  8:26   ` kernel test robot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).