[lkml]   [2019]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/3] mm/filemap: initiate readahead even if IOCB_NOWAIT is set for the I/O
On Thu, 31 Jan 2019, Florian Weimer wrote:

> >> I think this needs to use a different flag because the semantics are so
> >> much different. If I understand this change correctly, previously,
> >> RWF_NOWAIT essentially avoided any I/O, and now it does not.
> >
> > It still avoid synchronous I/O, due to this code still being in place:
> >
> > if (!PageUptodate(page)) {
> > if (iocb->ki_flags & IOCB_NOWAIT) {
> > put_page(page);
> > goto would_block;
> > }
> >
> > but goes the would_block path only after initiating asynchronous
> > readahead.
> But it wouldn't schedule asynchronous readahead before?

It would, that's kind of the whole point.

> I'm worried that something, say PostgreSQL doing a sequential scan,
> would implement a two-pass approach, first using RWF_NOWAIT to process
> what's in the kernel page cache, and then read the rest without it. If
> RWF_NOWAIT is treated as a prefetch hint, there could be much more read
> activity, and a lot of it would be pointless because the data might have
> to be evicted before userspace can use it.

So are you aware of anything already existing, that'd implement this
semantics? I've quickly grepped for
RWF_NOWAIT, and they don't seem to use it at all. RWF_NOWAIT is rather

The usecase I am aware of is to make sure that the thread doing
io_submit() doesn't get blocked for too long, because it has other things
to do quickly in order to avoid starving other sub-threads (and delegate
the I/O submission to asynchronous context).

Jiri Kosina

 \ /
  Last update: 2019-01-31 12:35    [W:0.096 / U:3.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site