On Sun, 09 Jan 2011 12:25:41 PST ron minnich <rminn...@gmail.com> wrote: > On Sun, Jan 9, 2011 at 11:54 AM, Bakul Shah <bakul+pl...@bitblocks.com> wrote > : > >None of these > > use any streaming (though there *is* readahead at the FS > > level). > > yes, all the systems that perform well do so via aggressive readahead > -- which, from one point of view, is one way of creating a stream from > a discrete set of requests.
On freebsd there is no readahead when dding from /dev/zero or /dev/md0 or any device for that matter (at least that used to be the case). Readahead is only at the FS level. That is why I showed dd numbers for devices -- freebsd does well even when there is no readahead. May be plan9 does too -- I would run these tests but I don't have plan9 on a fast machine. Readahead is a bet that the next block will be needed. Distinct from streaming (making sure we can *transfer* data as fast as possible). You don't need readahead if you can generate data fast enough! > If you think about it, a single 9p connection is a multiplexed stream > for managing file I/O requests. What john's work did is to create an > individual stream for each file. And, as Andrey's results and John's > results show, it can be a win. The existence of readahead supports the > idea that some form of streaming might work well in even the local > area. Windowing overhead (as in TCP) is not necessary but file readahead is a win in the local case. There are really N separate knobs you can tune: - read ahead - windowing (when latency*bandwidth is large) - parallelism - other local optimizations (does plan9 pay marshalling, unmarshalling cost for node local communication?) - pushing performance sensitive code into kernel (to reduce context switches). - more generally, collapsing code paths that go through multiple servers - zero copy data transfer Of course, some are worth doing *only* if you want absolutely the very best performance but they come at the cost of reduced flexibility, increased complexity & codebloat.
