Messages in this thread | | | Date | Tue, 2 Dec 2014 14:42:00 -0800 | From | Andrew Morton <> | Subject | Re: [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.
| |