lkml.org 
[lkml]   [2014]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v6 0/7] vfs: Non-blockling buffered fs read (page cache only)
On Tue, 2 Dec 2014 17:17:42 -0500 Milosz Tanski <milosz@adfin.com> 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.



\
 
 \ /
  Last update: 2014-12-03 00:21    [W:0.064 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site