On Tue, Jan 14, 2020 at 11:42:43PM -0800, Matthew Wilcox wrote:
> On Tue, Jan 14, 2020 at 11:16:28PM -0800, Christoph Hellwig wrote:
> > On Tue, Jan 14, 2020 at 06:38:40PM -0800, Matthew Wilcox wrote:
> > > +iomap_readahead(struct address_space *mapping, pgoff_t start,
> > > unsigned nr_pages, const struct iomap_ops *ops)
> > > {
> > > struct iomap_readpage_ctx ctx = {
> > > - .pages = pages,
> > > .is_readahead = true,
> > > };
> > > - loff_t pos = page_offset(list_entry(pages->prev, struct page, lru));
> > > - loff_t last = page_offset(list_entry(pages->next, struct page, lru));
> > > - loff_t length = last - pos + PAGE_SIZE, ret = 0;
> > > + loff_t pos = start * PAGE_SIZE;
> > > + loff_t length = nr_pages * PAGE_SIZE;
> >
> > Any good reason not to pass byte offsets for start and length?
> >
> > > + return length / PAGE_SIZE;
> >
> > Same for the return value?
> >
> > For the file systems that would usually be a more natural interface than
> > a page index and number of pages.
>
> That seems to depend on the filesystem. iomap definitely would be happier
> with loff_t, but cifs prefers pgoff_t. I should probably survey a few
> more filesystems and see if there's a strong lean in one direction or
> the other.
I've converted all the filesystems now except for those that use fscache.
http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/readahead
iomap is the only one for which an loff_t makes sense as an argument.
fscache will also prefer page index & count once Dave's conversion series
lands:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fscache-iter&id=ae317744dfb9732123e554467a9f6d93733e8a5b
I'll prep a serious conversion series for 5.6 soon (skipping cifs, but
converting all the non-fscache filesystems).
