Re: [PATCH RFC v4 2/3] iomap: use BIO_COMPLETE_IN_TASK for dropbehind writeback

[Gao Xiang]

Hi Christiph,

On 2026/3/27 14:08, Christoph Hellwig wrote:
> On Thu, Mar 26, 2026 at 07:34:45AM +1100, Dave Chinner wrote:
> > At this point, I'd suggest that we should not be making random
> > one-off changes to the iomap and filesystem layers like this just
> > for one operation that needs deferred IO completion work. This needs
> > to considered from the overall perspective of how we defer
> > completion work -  there are lots of different paths through
> > filesystems and/or iomap that require/use task deferal for IO
> > completion. We want them all to use the same mechanism - splitting
> > deferal between multiple layers depending on IO type is not a
> > particularly nice thing to be doing...
>
> Yes and no.  The XFS/iomap write completions needs special handling
> for merging operation, using different workqueues, and also the
> serialization provided by the per-inode list.
>
> Everything that just needs a dumb user context should be the same,
> though.  And this mechanism should work just fine for the T10 PI
> checksums.  It does not currently work for the defer to user on error
> used by the fserror reporting, but should be adaptable to that by
> allowing to also defer an I/O completion from an already running
> end_io handler, although that might get ugly.
>
> It should work really well for other places that defer bio completions
> like the erofs decompression handler that recently came up, and it will

I noticed this work, but typically the current EROFS
decompression has two latency-sensitive cases:

 - dm-verity calls EROFS completion, yes, in that case, this
   work can work well since dm-verity already takes some
   merkle tree latencies, and we just don't want to add more
   scheduling latencies with another workqueue;

 - use EROFS directly, in that case, we still need process
   contexts to decompress, but due to Android latency
   requirements, they really need per-cpu RT threads instead,
   otherwise it will cause serious regression too; but I'm not
   sure that case can be replaced by this work since workqueues
   don't support RT threads and I guess generic block layer
   won't be bothered with that too.

Thanks,
Gao Xiang

> be very useful to implement actually working REQ_NOWAIT support for
> file system writes.  So yes, I think we need to look more at the whole
> picture, and I think this is a good building block considering the
> whole picture.  I don't think we can coverge on just a single mechanism,
> but having few and generic ones is good.