Jeff, Which git repository do the man pages live in? - Milosz On Tue, Sep 16, 2014 at 3:30 PM, Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: > Milosz Tanski <milosz@xxxxxxxxx> writes: > >> This patcheset introduces an ability to perform a non-blocking read from >> regular files in buffered IO mode. This works by only for those filesystems >> that have data in the page cache. >> >> It does this by introducing new syscalls new syscalls readv2/writev2 and >> preadv2/pwritev2. These new syscalls behave like the network sendmsg, recvmsg >> syscalls that accept an extra flag argument (O_NONBLOCK). >> >> It's a very common patern today (samba, libuv, etc..) use a large threadpool to >> perform buffered IO operations. They submit the work form another thread >> that performs network IO and epoll or other threads that perform CPU work. This >> leads to increased latency for processing, esp. in the case of data that's >> already cached in the page cache. >> >> With the new interface the applications will now be able to fetch the data in >> their network / cpu bound thread(s) and only defer to a threadpool if it's not >> there. In our own application (VLDB) we've observed a decrease in latency for >> "fast" request by avoiding unnecessary queuing and having to swap out current >> tasks in IO bound work threads. >> >> I have co-developed these changes with Christoph Hellwig, a whole lot of his >> fixes went into the first patch in the series (were squashed with his >> approval). >> >> I am going to post the perf report in a reply-to to this RFC. > > You can send the performance data along with the patch series, no need to > separate it off in a reply. > > One additional patch I'd like to see is a man page update. That would > help clarify exactly what you're trying to accomplish. > > I look forward to v2! > > Cheers, > Jeff -- Milosz Tanski CTO 16 East 34th Street, 15th floor New York, NY 10016 p: 646-253-9055 e: milosz@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
