From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Sun, 09 Jan 2011 12:25:41 PST." References: <16094d5a594bfa72dd0e9ac6f3f8b31c@plug.quanstro.net> <20110109195426.D1ED35B42@mail.bitblocks.com> From: Bakul Shah Date: Sun, 9 Jan 2011 13:17:53 -0800 Message-Id: <20110109211753.79CFB5B42@mail.bitblocks.com> Subject: Re: [9fans] fs performance Topicbox-Message-UUID: 92fef10c-ead6-11e9-9d60-3106f5b1d025 On Sun, 09 Jan 2011 12:25:41 PST ron minnich wrote: > On Sun, Jan 9, 2011 at 11:54 AM, Bakul Shah 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.