Date: Thu, 15 May 1997 14:10:28 -0400 From: "David S. Miller" <davem@jenolan.rutgers.edu> To: terry@lambert.org Cc: ejc@bazzle.com, james@westongold.com, freebsd-hackers@FreeBSD.ORG Subject: Re: mmap() Message-ID: <199705151810.OAA01276@jenolan.caipgeneral> In-Reply-To: <199705151709.KAA15089@phaeton.artisoft.com> (message from Terry Lambert on Thu, 15 May 1997 10:09:21 -0700 (MST))
next in thread | previous in thread | raw e-mail | index | archive | help
From: Terry Lambert <terry@lambert.org> Date: Thu, 15 May 1997 10:09:21 -0700 (MST) This is not to say the situation is hopeless; you *could* crank up the sequential I/O performance of mmap(), at a cost of a save and compare in the general page fault case. Or you could add intelligent page prefetching/prefaulting, see the JACM article on prefetching about 3 or 4 issues ago for an extremely clever strategy to pull this off in an online fashion. Although be careful, their scheme is patented, but you could implement something similar just using something other than LNZ compression code selection (ie. use another compression scheme's code selection). There is proof even in the computer learning field that this is an extremely effective limited history prefetching strategy. ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705151810.OAA01276>