Re: [PATCH v6 0/7] vfs: Non-blockling buffered fs read (page cache only)

[Andrew Morton]

On Tue, 2 Dec 2014 17:17:42 -0500 Milosz Tanski <milosz@xxxxxxxxx> wrote:

> > There have been several incomplete attempts to implement fincore().  If
> > we were to complete those attempts, preadv2() could be implemented
> > using fincore()+pread().  Plus we get fincore(), which is useful for
> > other (but probably similar) reasons.  Probably fincore()+pwrite() could
> > be used to implement pwritev2(), but I don't know what pwritev2() does
> > yet.
> >
> > Implementing fincore() is more flexible, requires less code and is less
> > likely to have bugs.  So why not go that way?  Yes, it's more CPU
> > intensive, but how much?  Is the difference sufficient to justify the
> > preadv2()/pwritev2() approach?
> 
> I would like to see a fincore() functionality (for other reasons) I
> don't think it does the job here. fincore() + preadv() is inherently
> racy as there's no guarantee that the data becomes uncached between
> the two calls.

There will always be holes.  For example find_get_page() could block on
lock_page() while some other process is doing IO. 
page_cache_async_readahead() does lots of memory allocation which can
get blocked for long periods in the page allocator. 
page_cache_async_readahead() can block on synchronous metadata reads,
etc.

The question is whether a simpler approach such as fincore() will be
sufficient.

> This may not matter in some cases, but in others (ones
> that I'm trying to solve) it will introduce unexpected latency.

Details?

> There's no overlap between prwritev2 and fincore() functionality.

Do we actually need pwritev2()?  What's the justification for that?


Please let's examine the alternative(s) seriously.  It would be mistake
to add preadv2/pwritev2 if fincore+pread would have sufficed.  

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/