lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <x49sijrxt1f.fsf@segfault.boston.devel.redhat.com> Date: Tue, 16 Sep 2014 15:30:04 -0400 From: Jeff Moyer <jmoyer@...hat.com> To: Milosz Tanski <milosz@...in.com> Cc: linux-kernel@...r.kernel.org, Christoph Hellwig <hch@...radead.org>, linux-fsdevel@...r.kernel.org, linux-aio@...ck.org, Mel Gorman <mgorman@...e.de>, Volker Lendecke <Volker.Lendecke@...net.de>, Tejun Heo <tj@...nel.org> Subject: Re: [RFC PATCH 0/7] Non-blockling buffered fs read (page cache only) Milosz Tanski <milosz@...in.com> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists