On Wed, 24 Jun 2009 16:08:25 +0200 Joerg Sonnenberger <[email protected]> said:
> 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. i know. as will munap().. and it makes your stats look better - madvise will not. > 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*). older arm's will use jffs2 or cramfs - and this doesn't allow free mmap's - it has to lead and decode the whole file thanks to compression. :) > 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. you will need to be able to map and unamp - for updates. regardless. > Joerg > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
