From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/5] iomap: allow the file system to provide a bio_set for direct I/O
Date: Thu, 5 May 2022 08:38:33 -0700 [thread overview]
Message-ID: <20220505153833.GA27155@magnolia> (raw)
In-Reply-To: <20220504162342.573651-2-hch@lst.de>
On Wed, May 04, 2022 at 09:23:38AM -0700, Christoph Hellwig wrote:
> Allow the file system to provide a specific bio_set for allocating
> direct I/O bios. This will allow file systems that use the
> ->submit_io hook to stash away additional information for file system
> use.
>
> To make use of this additional space for information in the completion
> path, the file system needs to override the ->bi_end_io callback and
> then call back into iomap, so export iomap_dio_bio_end_io for that.
I hear reports of people (Ted) at LSF asking for better support in
porting things to iomap. Can we document the entire process of using
additional space per bio somewhere in the header file?
/*
* Filesystems wishing to attach private information to a directio bio
* must provide a ->submit_io method that attaches the additional
* information to the bio and changes the ->bi_end_io callback to a
* custom function. This function should, at a minimum, perform any
* relevant post-processing of the bio and end with a call to
* iomap_dio_bio_end_io.
*/
I'm not sure where this would go in iomap.h, since this is more about
custom bios than it is about biosets, but I think we could at least try
to seed future converter patchset authors with some reasonable recipes
so we don't end up with the sprawling messes that we have with
bufferheads. Obviously, adding recipes is not something in scope for
this patch.
This patch looks ok, so
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> fs/iomap/direct-io.c | 18 ++++++++++++++----
> include/linux/iomap.h | 3 +++
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> index b08f5dc31780d..15929690d89e3 100644
> --- a/fs/iomap/direct-io.c
> +++ b/fs/iomap/direct-io.c
> @@ -51,6 +51,15 @@ struct iomap_dio {
> };
> };
>
> +static struct bio *iomap_dio_alloc_bio(const struct iomap_iter *iter,
> + struct iomap_dio *dio, unsigned short nr_vecs, unsigned int opf)
> +{
> + if (dio->dops && dio->dops->bio_set)
> + return bio_alloc_bioset(iter->iomap.bdev, nr_vecs, opf,
> + GFP_KERNEL, dio->dops->bio_set);
> + return bio_alloc(iter->iomap.bdev, nr_vecs, opf, GFP_KERNEL);
> +}
> +
> static void iomap_dio_submit_bio(const struct iomap_iter *iter,
> struct iomap_dio *dio, struct bio *bio, loff_t pos)
> {
> @@ -144,7 +153,7 @@ static inline void iomap_dio_set_error(struct iomap_dio *dio, int ret)
> cmpxchg(&dio->error, 0, ret);
> }
>
> -static void iomap_dio_bio_end_io(struct bio *bio)
> +void iomap_dio_bio_end_io(struct bio *bio)
> {
> struct iomap_dio *dio = bio->bi_private;
> bool should_dirty = (dio->flags & IOMAP_DIO_DIRTY);
> @@ -176,16 +185,17 @@ static void iomap_dio_bio_end_io(struct bio *bio)
> bio_put(bio);
> }
> }
> +EXPORT_SYMBOL_GPL(iomap_dio_bio_end_io);
>
> static void iomap_dio_zero(const struct iomap_iter *iter, struct iomap_dio *dio,
> loff_t pos, unsigned len)
> {
> struct inode *inode = file_inode(dio->iocb->ki_filp);
> struct page *page = ZERO_PAGE(0);
> - int flags = REQ_SYNC | REQ_IDLE;
> struct bio *bio;
>
> - bio = bio_alloc(iter->iomap.bdev, 1, REQ_OP_WRITE | flags, GFP_KERNEL);
> + bio = iomap_dio_alloc_bio(iter, dio, 1,
> + REQ_OP_WRITE | REQ_SYNC | REQ_IDLE);
> fscrypt_set_bio_crypt_ctx(bio, inode, pos >> inode->i_blkbits,
> GFP_KERNEL);
> bio->bi_iter.bi_sector = iomap_sector(&iter->iomap, pos);
> @@ -311,7 +321,7 @@ static loff_t iomap_dio_bio_iter(const struct iomap_iter *iter,
> goto out;
> }
>
> - bio = bio_alloc(iomap->bdev, nr_pages, bio_opf, GFP_KERNEL);
> + bio = iomap_dio_alloc_bio(iter, dio, nr_pages, bio_opf);
> fscrypt_set_bio_crypt_ctx(bio, inode, pos >> inode->i_blkbits,
> GFP_KERNEL);
> bio->bi_iter.bi_sector = iomap_sector(iomap, pos);
> diff --git a/include/linux/iomap.h b/include/linux/iomap.h
> index b76f0dd149fb4..a5483020dad41 100644
> --- a/include/linux/iomap.h
> +++ b/include/linux/iomap.h
> @@ -320,6 +320,8 @@ struct iomap_dio_ops {
> unsigned flags);
> void (*submit_io)(const struct iomap_iter *iter, struct bio *bio,
> loff_t file_offset);
> +
> + struct bio_set *bio_set;
> };
>
> /*
> @@ -349,6 +351,7 @@ struct iomap_dio *__iomap_dio_rw(struct kiocb *iocb, struct iov_iter *iter,
> const struct iomap_ops *ops, const struct iomap_dio_ops *dops,
> unsigned int dio_flags, size_t done_before);
> ssize_t iomap_dio_complete(struct iomap_dio *dio);
> +void iomap_dio_bio_end_io(struct bio *bio);
>
> #ifdef CONFIG_SWAP
> struct file;
> --
> 2.30.2
>
next prev parent reply other threads:[~2022-05-05 15:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-04 16:23 reduce memory allocation in the btrfs direct I/O path Christoph Hellwig
2022-05-04 16:23 ` [PATCH 1/5] iomap: allow the file system to provide a bio_set for direct I/O Christoph Hellwig
2022-05-05 15:38 ` Darrick J. Wong [this message]
2022-05-04 16:23 ` [PATCH 2/5] iomap: add per-iomap_iter private data Christoph Hellwig
2022-05-05 8:06 ` Nikolay Borisov
2022-05-05 15:06 ` Christoph Hellwig
2022-05-05 15:41 ` Darrick J. Wong
2022-05-05 15:45 ` Christoph Hellwig
2022-05-05 16:32 ` Darrick J. Wong
2022-05-05 18:15 ` Christoph Hellwig
2022-05-05 18:18 ` Darrick J. Wong
2022-05-04 16:23 ` [PATCH 3/5] btrfs: add a btrfs_dio_rw wrapper Christoph Hellwig
2022-05-04 16:23 ` [PATCH 4/5] btrfs: allocate dio_data on stack Christoph Hellwig
2022-05-04 16:23 ` [PATCH 5/5] btrfs: allocate the btrfs_dio_private as part of the iomap dio bio Christoph Hellwig
2022-05-05 8:12 ` Nikolay Borisov
2022-05-05 15:07 ` Christoph Hellwig
2022-05-05 15:20 ` David Sterba
2022-05-05 15:52 ` David Sterba
2022-05-05 8:33 ` reduce memory allocation in the btrfs direct I/O path Nikolay Borisov
2022-05-05 15:55 ` David Sterba
2022-05-06 17:18 ` Darrick J. Wong
2022-05-07 5:26 ` Christoph Hellwig
2022-05-09 18:46 ` David Sterba
2022-05-10 3:33 ` Darrick J. Wong
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=20220505153833.GA27155@magnolia \
--to=djwong@kernel.org \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=hch@lst.de \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.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 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).