Re: [PATCHSET v3 0/4] Submit ->readpages() IO as read-ahead

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 30 May 2018 08:42:05 -0600 Jens Axboe <axboe@kernel.dk> wrote:

> The only caller of ->readpages() is from read-ahead, yet we don't
> submit IO flagged with REQ_RAHEAD. This means we don't see it in
> blktrace, for instance, which is a shame. We already make assumptions
> about ->readpages() just being for read-ahead in the mpage
> implementation, using readahead_gfp_mask(mapping) as out GFP mask of
> choice.
> 
> This small series fixes up mpage_readpages() to submit with
> REQ_RAHEAD, which takes care of file systems using mpage_readpages().
> The first patch is a prep patch, that makes do_mpage_readpage() take
> an argument structure.

Well gee.  That sounds like a total fluke and I don't see anything
which prevents future code from using readpages for something other
than readahead.

For example, f2fs_mpage_readpages().  Which, being f2fs, has decided to
copy-paste-modify mpage_readpages() and to then use it for
non-readahead purposes.  If that code ever gets its act together then
we have a problem.

A proper approach might be to add a new
address_space_operations.readahead which sets REQ_RAHEAD but after
doing all that, nothing would use address_space_operations.readpages,
which is a bit weird.

And what's happening with the individual ->readpage() calls which
read_pages() does?  Do they still not get REQ_RAHEAD treatment?


This is kinda dirty, but we could add a readahead flag to blk_plug, set
it in read_pages(), test it down in the block layer somewhere....
That's grubby, but at least it wouldn't increase sizeof(task_struct)?