All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Ming Lei <ming.lei@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org,
	Mikulas Patocka <mpatocka@redhat.com>,
	Zhaoyang Huang <zhaoyang.huang@unisoc.com>,
	Dave Chinner <dchinner@redhat.com>,
	linux-fsdevel@vger.kernel.org, io-uring@vger.kernel.org
Subject: Re: [PATCH V4 6/6] loop: add hint for handling aio via IOCB_NOWAIT
Date: Tue, 7 Oct 2025 22:56:01 -0700	[thread overview]
Message-ID: <aOX88d7GrbhBkC51@infradead.org> (raw)
In-Reply-To: <aOUESdhW-joMHvyW@fedora>

On Tue, Oct 07, 2025 at 08:15:05PM +0800, Ming Lei wrote:
> NOWAIT is obviously interface provided by FS, here loop just wants to try
> NOWAIT first in block layer dispatch context for avoiding the extra wq
> schedule latency.

Yes.

> But for write on sparse file, trying NOWAIT first may bring extra retry
> cost, that is why the hint is added. It is very coarse, but potential
> regression can be avoided.

And that is absolutely not a property of loop, and loop should not have
to know about.  So this logic needs to be in common code, preferably
triggered by a fs flag.  Note that this isn't about holes - it is about
allocating blocks.  For most file systems filling holes or extending
past i_size is what requires allocating blocks.  But for a out of place
write file systems like btrfs, or zoned xfs we always need to allocate
blocks for now.  But I have work that I need to finish off that allows
for non-blocking block allocation in zoned XFS, at which point you
don't need this.  I think some of this might be true for network file
systems already.

> 
> > rather have a flag similar FOP_DIO_PARALLEL_WRITE that makes this
> > limitation clear rather then opencoding it in the loop driver while
> 
> What is the limitation?

See above.

> > leabing the primary user of RWF_NOWAIT out in the cold.
> 
> FOP_DIO_PARALLEL_WRITE is one static FS feature,

It actually isn't :( I need to move it to be a bit more dynamic on a
per-file basis.

> but here it is FS
> runtime behavior, such as if the write can be blocked because of space
> allocation, so it can't be done by one static flag.

Yes, that's why you want a flag to indicate that a file, or maybe file
operations instance can do non-blocking fill of blocks.  But that's
for the future, for now I just want your logic lifted to common code
and shared with io_uring so that we don't have weird hardcoded
assumptions about file system behavior inside the loop driver.

> io-uring shares nothing with loop in this area, it is just one policy wrt.
> use NOWAIT or not. I don't understand why you insist on covering both
> from FS internal...

It's really about all IOCB_NOWAIT users, io_uring being the prime one,
and the one that we can actually easily write tests for.


  reply	other threads:[~2025-10-08  5:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-28 13:29 [PATCH V4 0/6] loop: improve loop aio perf by IOCB_NOWAIT Ming Lei
2025-09-28 13:29 ` [PATCH V4 1/6] loop: add helper lo_cmd_nr_bvec() Ming Lei
2025-10-03  7:04   ` Christoph Hellwig
2025-09-28 13:29 ` [PATCH V4 2/6] loop: add helper lo_rw_aio_prep() Ming Lei
2025-10-03  7:04   ` Christoph Hellwig
2025-09-28 13:29 ` [PATCH V4 3/6] loop: add lo_submit_rw_aio() Ming Lei
2025-10-03  7:04   ` Christoph Hellwig
2025-09-28 13:29 ` [PATCH V4 4/6] loop: move command blkcg/memcg initialization into loop_queue_work Ming Lei
2025-09-28 13:29 ` [PATCH V4 5/6] loop: try to handle loop aio command via NOWAIT IO first Ming Lei
2025-09-29  6:44   ` Yu Kuai
2025-09-29  9:18     ` Ming Lei
2025-09-28 13:29 ` [PATCH V4 6/6] loop: add hint for handling aio via IOCB_NOWAIT Ming Lei
2025-10-03  7:06   ` Christoph Hellwig
2025-10-06 14:18     ` Ming Lei
2025-10-07  6:33       ` Christoph Hellwig
2025-10-07 12:15         ` Ming Lei
2025-10-08  5:56           ` Christoph Hellwig [this message]
2025-10-09  1:25             ` Ming Lei
2025-10-13  6:26               ` Christoph Hellwig
2025-10-13  8:26                 ` Ming Lei
2025-09-28 18:42 ` [syzbot ci] Re: loop: improve loop aio perf by IOCB_NOWAIT syzbot ci
2025-09-29  1:13   ` Ming Lei

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=aOX88d7GrbhBkC51@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=dchinner@redhat.com \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=mpatocka@redhat.com \
    --cc=zhaoyang.huang@unisoc.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 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.