Re: [PATCH 1/1] iomap: propagate nowait to block layer

[Pavel Begunkov <asml.silence@gmail.com>]

On 2/26/25 02:20, Darrick J. Wong wrote:
> On Wed, Feb 26, 2025 at 02:06:51AM +0000, Pavel Begunkov wrote:
>> On 2/26/25 01:53, Darrick J. Wong wrote:
>>> On Wed, Feb 26, 2025 at 01:33:58AM +0000, Pavel Begunkov wrote:
>>>> There are reports of high io_uring submission latency for ext4 and xfs,
>>>> which is due to iomap not propagating nowait flag to the block layer
>>>> resulting in waiting for IO during tag allocation.
>>>>
>>>> Cc: stable@vger.kernel.org
>>>> Link: https://github.com/axboe/liburing/issues/826#issuecomment-2674131870
>>>> Reported-by: wu lei <uwydoc@gmail.com>
>>>> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
>>>> ---
>>>>    fs/iomap/direct-io.c | 3 +++
>>>>    1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
>>>> index b521eb15759e..25c5e87dbd94 100644
>>>> --- a/fs/iomap/direct-io.c
>>>> +++ b/fs/iomap/direct-io.c
>>>> @@ -81,6 +81,9 @@ static void iomap_dio_submit_bio(const struct iomap_iter *iter,
>>>>    		WRITE_ONCE(iocb->private, bio);
>>>>    	}
>>>> +	if (iocb->ki_flags & IOCB_NOWAIT)
>>>> +		bio->bi_opf |= REQ_NOWAIT;
>>>
>>> Shouldn't this go in iomap_dio_bio_opflags?
>>
>> It can, if that's the preference, but iomap_dio_zero() would need
>> to have a separate check. It also affects 5.4, and I'm not sure
>> which version would be easier to back port.
> 
> Yes, please don't go scattering the bi_opf setting code all around the

Sure, even though the function already adjusts bi_opf through
bio_set_polled.

> file.  Also, do you need to modify iomap_dio_zero?

Is there a reason why it can't be hit? It's in the same path, and
from a quick look ending up there seems as easy as writing just a
little beyond the file size.

-- 
Pavel Begunkov