On Fri, 2007-02-16 at 03:05 -0800, Dan Price wrote:
On Fri 16 Feb 2007 at 02:49AM, Dan Price wrote:
So.. Hmm. Could the problem simply be that the mmap-copy-growing is too slow? If the user really has some 25MB cache file, that could be it. I think I could change the code so that it mmap()s immediately enough memory to fit the whole cache file. Probably a good idea to do anyway.
One thing I don't totally get is why you mmap anon here, if this is really about a cache file? It seems that you could mmap the cache file directly, perhaps with MAP_PRIVATE if you need to make in-memory-only changes.
Yes, and it's done as long as you don't have mmap_disable=yes. Hmm. Weren't you using ZFS directly? Why are you using mmap_disable=yes? :) Its main purpose is to make indexes work in NFS.
I agree that mmaping the whole index.cache in one shot is the way to go-- asking the VM system to do work in little chunks is (at least on Solaris) a real performance killer.
Another idea I had was that dovecot could take advantage of larger pages--especially for its anon mappings-- this cuts TLB footprint and is usually "a good thing."
So for example, on Solaris (SPARC) you can get 8K, 64K, 512K and 4M pages. On Solaris AMD64 it's 4K and 2M.
This is available via getpagesizes(3c).
I haven't heard about this before. I'll see if I can use it.