Date: Thu, 3 Oct 1996 10:35:19 +0100 (BST) From: Doug Rabson <dfr@render.com> To: dyson@freebsd.org Cc: phk@critter.tfs.com, heo@cslsun10.sogang.ac.kr, freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Subject: Re: vnode and cluster read-ahead Message-ID: <Pine.BSF.3.95.961003102610.10204O-100000@minnow.render.com> In-Reply-To: <199610021740.MAA01329@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Oct 1996, John Dyson wrote: > > > > You could maintain a number of 'pending readahead' structures indexed by > > vnode and block number. Each call to cluster_read would check for a > > pending readahead by hashing. For efficiency, keep a pointer to the last > > readahead structure used by cluster_read in the vnode in place of the > > existing in-vnode readahead data. Should be no slower than the current > > system for single process reads and it saves 4 bytes per vnode :-). > > > Pretty cool idea. I am remembering now that this deficiency in our read > ahead code is well known. This might be something really good for 2.3 or > 3.1 :-). (Unless someone else wants to implement it -- hint hint :-)). On the subject of saving memory, I firmly believe that signficant performance improvements can be made just by reducing the memory footprint of algorithms. In our 3D graphics work, we have found that making important datastructures fit into cache lines (and using an aligning allocator to make sure that they start on cache line boundaries) can improve performance by as much as 20%. When future processors from Intel will have clock speeds of 400Mhz and above but have a 75Mhz memory bus to level 2 cache, this will become even more important towards the end of '97 and beyond. The size of a piece of software and its memory usage patterns will dominate its performance profile. Maybe we need a 'Campaign for Small Software' :-). -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961003102610.10204O-100000>