On Wed, Jun 24, 2009 at 11:40:06PM +1000, Carsten Haitzler wrote: > > > unmapping should help give a hint... it also looks better in top/ps :) > > > > The first part is already done by using madvise. It doesn't forcefully > > trash the VM space though. > > neither does munmap() - it sits in cache. (as it does when mmaped()). but it > looks better when looking at mem footprint and provides an extra hint to the > kernel - if mapped, the kernel can assume that at some point you may need the > data - when not mapped, it can just put it in speculative cache and forget > about it.
posix_madvise(2) with POSIX_MADV_DONTNEED provides the same effect with regard to caching as munmap(2) does. It does not force the overhead of changing the VM space though. This is especially visible on SMP systems. There are some other use cases of mmap(2) that should be avoided if possible, e.g. mapping read-write of the same file in multiple processes at different locations can be very expensive for some brain-damaged MMU designs (older ARMs *cough*). Basically, if you want to help the OS to to free the cache, madvise(2) is much easier from the programming point of view. It also reduces the number of possible errors. I'm not even sure how much is really gained by allowing the cache to drop out of memory. E.g. share/mime is 3MB on my system and the XML representation is not exactly storage efficient. Joerg ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
