Re: [PATCH 8/8] iomap: support IOCB_DIO_DEFER

Jens Axboe
2023-07-21T16:33:31Z

On 7/21/23 10:01?AM, Darrick J. Wong wrote:
>> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
>> index cce9af019705..de86680968a4 100644
>> --- a/fs/iomap/direct-io.c
>> +++ b/fs/iomap/direct-io.c
>> @@ -20,6 +20,7 @@
>> * Private flags for iomap_dio, must not overlap with the public ones in
>> * iomap.h:
>> */
>> +#define IOMAP_DIO_DEFER_COMP (1 << 26)
>
> IOMAP_DIO_CALLER_COMP, to go with IOCB_CALLER_COMP?

Yep, already made that change in conjunction with the other rename.

>> #define IOMAP_DIO_INLINE_COMP (1 << 27)
>> + /*
>> + * If this dio is flagged with IOMAP_DIO_DEFER_COMP, then schedule
>> + * our completion that way to avoid an async punt to a workqueue.
>> + */
>> + if (dio->flags & IOMAP_DIO_DEFER_COMP) {
>> + /* only polled IO cares about private cleared */
>> + iocb->private = dio;
>> + iocb->dio_complete = iomap_dio_deferred_complete;
>> +
>> + /*
>> + * Invoke ->ki_complete() directly. We've assigned out
>
> "We've assigned our..."

Fixed.

>> @@ -288,12 +319,17 @@ static loff_t iomap_dio_bio_iter(const struct iomap_iter *iter,
>> * after IO completion such as unwritten extent conversion) and
>> * the underlying device either supports FUA or doesn't have
>> * a volatile write cache. This allows us to avoid cache flushes
>> - * on IO completion.
>> + * on IO completion. If we can't use stable writes and need to
>
> "If we can't use writethrough and need to sync..."

Fixed.

>> @@ -319,6 +355,13 @@ static loff_t iomap_dio_bio_iter(const struct iomap_iter *iter,
>> pad = pos & (fs_block_size - 1);
>> if (pad)
>> iomap_dio_zero(iter, dio, pos - pad, pad);
>> +
>> + /*
>> + * If need_zeroout is set, then this is a new or unwritten
>> + * extent. These need extra handling at completion time, so
>
> "...then this is a new or unwritten extent, or dirty file metadata have
> not been persisted to disk."

Fixed.

--
Jens Axboe