Date: Sun, 26 Mar 2006 11:44:58 -0500 From: Mikhail Teterin <mi+kde@aldan.algebra.com> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: alc@freebsd.org, Mikhail Teterin <mi+mx@aldan.algebra.com>, stable@freebsd.org Subject: Re: Reading via mmap stinks (Re: weird bugs with mmap-ing via NFS) Message-ID: <200603261144.59238@aldan> In-Reply-To: <20060325234641.GA770@turion.vk2pj.dyndns.org> References: <200603232352.k2NNqPS8018729@gate.bitblocks.com> <200603241518.01027.mi%2Bmx@aldan.algebra.com> <20060325234641.GA770@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 25 March 2006 06:46 pm, Peter Jeremy wrote: = My guess is that the read-ahead algorithms are working but aren't doing = enough re-ahead to cope with "read a bit, do some cpu-intensive processing = and repeat" at 25MB/sec so you're winding up with a degree of serialisation = where the I/O and compressing aren't overlapped. I'm not sure how tunable = the read-ahead is. Well, is the MADV_SEQUNTIAL advice, given over the entire mmap-ed region, taken into account anywhere in the kernel? The kernel could read-ahead more aggressively if it freed the just accessed pages faster, than it does in the default case... Matt wrote in the same thread: = It is particularly possible when you combine read() with = mmap because read() uses a different heuristic then mmap() to = implement the read-ahead. There is also code in there which depresses = the page priority of 'old' already-read pages in the sequential case. Well, thanks for the theoretical confirmation of what I was trying to prove by experiments :-) Can this depressing of the "old" pages in the sequential case, that read's implementation already has, be also implemented in mmap's case? It may not *always* be, what the mmap-ing program wants, but when the said program uses MADV_SEQUENTAIL, it should not be ignored... (Bakul understood this point of mine 3 days ago :-) Peter Jeremy also wrote, in another message: = I can't test is as-is because it insists on mmap'ing its output and I only = have one disk and you can't mmap /dev/null. If you use a well compressible (redundant) file, such as a web-server log, and a high enough compression ratio, you can use the same disk for output -- the writes will be very infrequent. Thanks! Yours, -mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603261144.59238>