From: Jan Kara <jack@suse.cz>
To: Tang Yizhou <yizhou.tang@shopee.com>
Cc: jack@suse.cz, hch@infradead.org, willy@infradead.org,
akpm@linux-foundation.org, chandan.babu@oracle.com,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2 3/3] xfs: Let the max iomap length be consistent with the writeback code
Date: Mon, 7 Oct 2024 18:36:09 +0200 [thread overview]
Message-ID: <20241007163609.fkwiybr3nnw7utnc@quack3> (raw)
In-Reply-To: <20241006152849.247152-4-yizhou.tang@shopee.com>
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
next prev parent reply other threads:[~2024-10-07 16:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
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=20241007163609.fkwiybr3nnw7utnc@quack3 \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=chandan.babu@oracle.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=willy@infradead.org \
--cc=yizhou.tang@shopee.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