On Tue, Feb 18, 2020 at 07:10:44PM -0800, Eric Biggers wrote:
> > +``readahead``
> > + Called by the VM to read pages associated with the address_space
> > + object. The pages are consecutive in the page cache and are
> > + locked. The implementation should decrement the page refcount
> > + after starting I/O on each page. Usually the page will be
> > + unlocked by the I/O completion handler. If the function does
> > + not attempt I/O on some pages, the caller will decrement the page
> > + refcount and unlock the pages for you. Set PageUptodate if the
> > + I/O completes successfully. Setting PageError on any page will
> > + be ignored; simply unlock the page if an I/O error occurs.
> > +
>
> This is unclear about how "not attempting I/O" works and how that affects who is
> responsible for putting and unlocking the pages. How does the caller know which
> pages were not attempted? Can any arbitrary subset of pages be not attempted,
> or just the last N pages?
Changed to:
``readahead``
Called by the VM to read pages associated with the address_space
object. The pages are consecutive in the page cache and are
locked. The implementation should decrement the page refcount
after starting I/O on each page. Usually the page will be
unlocked by the I/O completion handler. If the filesystem decides
to stop attempting I/O before reaching the end of the readahead
window, it can simply return. The caller will decrement the page
refcount and unlock the remaining pages for you. Set PageUptodate
if the I/O completes successfully. Setting PageError on any page
will be ignored; simply unlock the page if an I/O error occurs.
