public inbox for [email protected]
 help / color / mirror / Atom feed
From: Ming Lei <[email protected]>
To: Pavel Begunkov <[email protected]>
Cc: Jens Axboe <[email protected]>,
	[email protected], Conrad Meyer <[email protected]>,
	[email protected], [email protected],
	[email protected]
Subject: Re: [RFC 5/5] block: implement io_uring discard cmd
Date: Fri, 16 Aug 2024 07:44:34 +0800	[thread overview]
Message-ID: <Zr6S4sHWtdlbl/dd@fedora> (raw)
In-Reply-To: <[email protected]>

On Thu, Aug 15, 2024 at 06:11:13PM +0100, Pavel Begunkov wrote:
> On 8/15/24 15:33, Jens Axboe wrote:
> > On 8/14/24 7:42 PM, Ming Lei wrote:
> > > On Wed, Aug 14, 2024 at 6:46?PM Pavel Begunkov <[email protected]> wrote:
> > > > 
> > > > Add ->uring_cmd callback for block device files and use it to implement
> > > > asynchronous discard. Normally, it first tries to execute the command
> > > > from non-blocking context, which we limit to a single bio because
> > > > otherwise one of sub-bios may need to wait for other bios, and we don't
> > > > want to deal with partial IO. If non-blocking attempt fails, we'll retry
> > > > it in a blocking context.
> > > > 
> > > > Suggested-by: Conrad Meyer <[email protected]>
> > > > Signed-off-by: Pavel Begunkov <[email protected]>
> > > > ---
> > > >   block/blk.h             |  1 +
> > > >   block/fops.c            |  2 +
> > > >   block/ioctl.c           | 94 +++++++++++++++++++++++++++++++++++++++++
> > > >   include/uapi/linux/fs.h |  2 +
> > > >   4 files changed, 99 insertions(+)
> > > > 
> > > > diff --git a/block/blk.h b/block/blk.h
> > > > index e180863f918b..5178c5ba6852 100644
> > > > --- a/block/blk.h
> > > > +++ b/block/blk.h
> > > > @@ -571,6 +571,7 @@ blk_mode_t file_to_blk_mode(struct file *file);
> > > >   int truncate_bdev_range(struct block_device *bdev, blk_mode_t mode,
> > > >                  loff_t lstart, loff_t lend);
> > > >   long blkdev_ioctl(struct file *file, unsigned cmd, unsigned long arg);
> > > > +int blkdev_uring_cmd(struct io_uring_cmd *cmd, unsigned int issue_flags);
> > > >   long compat_blkdev_ioctl(struct file *file, unsigned cmd, unsigned long arg);
> > > > 
> > > >   extern const struct address_space_operations def_blk_aops;
> > > > diff --git a/block/fops.c b/block/fops.c
> > > > index 9825c1713a49..8154b10b5abf 100644
> > > > --- a/block/fops.c
> > > > +++ b/block/fops.c
> > > > @@ -17,6 +17,7 @@
> > > >   #include <linux/fs.h>
> > > >   #include <linux/iomap.h>
> > > >   #include <linux/module.h>
> > > > +#include <linux/io_uring/cmd.h>
> > > >   #include "blk.h"
> > > > 
> > > >   static inline struct inode *bdev_file_inode(struct file *file)
> > > > @@ -873,6 +874,7 @@ const struct file_operations def_blk_fops = {
> > > >          .splice_read    = filemap_splice_read,
> > > >          .splice_write   = iter_file_splice_write,
> > > >          .fallocate      = blkdev_fallocate,
> > > > +       .uring_cmd      = blkdev_uring_cmd,
> > > 
> > > Just be curious, we have IORING_OP_FALLOCATE already for sending
> > > discard to block device, why is .uring_cmd added for this purpose?
> 
> Which is a good question, I haven't thought about it, but I tend to
> agree with Jens. Because vfs_fallocate is created synchronous
> IORING_OP_FALLOCATE is slow for anything but pretty large requests.
> Probably can be patched up, which would  involve changing the
> fops->fallocate protot, but I'm not sure async there makes sense
> outside of bdev (?), and cmd approach is simpler, can be made
> somewhat more efficient (1 less layer in the way), and it's not
> really something completely new since we have it in ioctl.

Yeah, we have ioctl(DISCARD), which acquires filemap_invalidate_lock,
same with blkdev_fallocate().

But this patch drops this exclusive lock, so it becomes async friendly,
but may cause stale page cache. However, if the lock is required, it can't
be efficient anymore and io-wq may be inevitable, :-)

Thanks,
Ming


  reply	other threads:[~2024-08-15 23:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-14 10:45 [RFC 0/5] implement asynchronous BLKDISCARD via io_uring Pavel Begunkov
2024-08-14 10:45 ` [RFC 1/5] io_uring/cmd: expose iowq to cmds Pavel Begunkov
2024-08-14 10:45 ` [RFC 2/5] io_uring/cmd: give inline space in request " Pavel Begunkov
2024-08-14 10:45 ` [RFC 3/5] filemap: introduce filemap_invalidate_pages Pavel Begunkov
2024-08-14 10:45 ` [RFC 4/5] block: introduce blk_validate_discard() Pavel Begunkov
2024-08-14 10:45 ` [RFC 5/5] block: implement io_uring discard cmd Pavel Begunkov
2024-08-15  1:42   ` Ming Lei
2024-08-15 14:33     ` Jens Axboe
2024-08-15 17:11       ` Pavel Begunkov
2024-08-15 23:44         ` Ming Lei [this message]
2024-08-16  1:24           ` Jens Axboe
2024-08-16  1:45             ` Ming Lei
2024-08-16  1:59               ` Pavel Begunkov
2024-08-16  2:08                 ` Ming Lei
2024-08-16  2:16                   ` Pavel Begunkov
2024-08-19 20:02                     ` Jens Axboe
2024-08-19 20:01               ` Jens Axboe
2024-08-20  2:36                 ` Ming Lei
2024-08-20 16:30                   ` Jens Axboe
2024-08-20 17:19                     ` Pavel Begunkov
2024-08-21  2:55                       ` Ming Lei
2024-08-15 14:42   ` Jens Axboe
2024-08-15 15:50 ` [RFC 0/5] implement asynchronous BLKDISCARD via io_uring Jens Axboe
2024-08-15 17:26   ` Pavel Begunkov
2024-08-15 16:15 ` Martin K. Petersen
2024-08-15 17:12   ` Pavel Begunkov

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=Zr6S4sHWtdlbl/dd@fedora \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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