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.
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).
For now, I'm going to try to change file_cache_set_size() to just artificially inflate page_size up to 4M-- at least that should make these resizes less frequent.
Thanks again for your help-- the fact that you take the time to support the community is a major factor in my decision to deploy dovecot.
-dp-- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp