Re: [PATCH 2/3] mm/filemap: initiate readahead even if IOCB_NOWAIT is set for the I/O

From: Jiri Kosina
Date: Tue Feb 12 2019 - 10:49:05 EST

On Fri, 1 Feb 2019, Dave Chinner wrote:

> So, I'll invite the incoherent, incandescent O_DIRECT rage flames of
> Linus to be unleashed again and point out the /other reference/ to
> IOCB_NOWAIT in mm/filemap.c. That is, in generic_file_read_iter(),
> in the *generic O_DIRECT read path*:
> if (iocb->ki_flags & IOCB_DIRECT) {
> .....
> if (iocb->ki_flags & IOCB_NOWAIT) {
> if (filemap_range_has_page(mapping, iocb->ki_pos,
> iocb->ki_pos + count - 1))
> return -EAGAIN;
> } else {
> .....

OK, thanks Dave, this is a good point I've missed in this mail before
(probabably as I focused only on the aspect of disagreement what NONBLOCK
actually means :) ). I will look into fixing it for next iteration.

> It's effectively useless as a workaround because you can avoid the
> readahead IO being issued relatively easily:
> void page_cache_sync_readahead(struct address_space *mapping,
> struct file_ra_state *ra, struct file *filp,
> pgoff_t offset, unsigned long req_size)
> {
> /* no read-ahead */
> if (!ra->ra_pages)
> return;
> if (blk_cgroup_congested())
> return;
> ....
> IOWs, we just have to issue enough IO to congest the block device (or,
> even easier, a rate-limited cgroup), and we can still use RWF_NOWAIT
> to probe the page cache. Or if we can convince ra->ra_pages to be
> zero (e.g. it's on bdi device with no readahead configured because
> it's real fast) then it doesn't work there, either.

It's though questionable whether the noise level here wouldn't be too high
already for any sidechannel to work reliably. So I'd suggest to operate
under the assumption that it would be too noisy, unless anyone is able to
prove otherwise.


Jiri Kosina