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-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
