Thread (23 messages) 23 messages, 3 authors, 2025-09-24

Re: [PATCH v4 10/15] iomap: add bias for async read requests

From: Joanne Koong <joannelkoong@gmail.com>
Date: 2025-09-24 18:23:14
Also in: gfs2, linux-doc, linux-fsdevel, linux-xfs

On Tue, Sep 23, 2025 at 5:28 PM Darrick J. Wong [off-list ref] wrote:
On Mon, Sep 22, 2025 at 05:23:48PM -0700, Joanne Koong wrote:
quoted
Non-block-based filesystems will be using iomap read/readahead. If they
handle reading in ranges asynchronously and fulfill those read requests
on an ongoing basis (instead of all together at the end), then there is
the possibility that the read on the folio may be prematurely ended if
earlier async requests complete before the later ones have been issued.

For example if there is a large folio and a readahead request for 16
pages in that folio, if doing readahead on those 16 pages is split into
4 async requests and the first request is sent off and then completed
before we have sent off the second request, then when the first request
calls iomap_finish_folio_read(), ifs->read_bytes_pending would be 0,
which would end the read and unlock the folio prematurely.

To mitigate this, a "bias" is added to ifs->read_bytes_pending before
the first range is forwarded to the caller and removed after the last
range has been forwarded.

iomap writeback does this with their async requests as well to prevent
prematurely ending writeback.
I'm still waiting for responses to the old draft of this patch in the v3
thread.
Ahh, thanks for clarifying that. I'll go back to that thread and get
some more alignment.

Thanks,
Joanne
--D
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help