[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-devel
Subject:    Re: [E-devel] [PATCH] Add distinguish the target site to gadgets
From:       Carsten Haitzler (The Rasterman) <raster () rasterman ! com>
Date:       2009-06-24 14:27:16
Message-ID: 20090625002716.e80e24eb.raster () rasterman ! com
[Download RAW message or body]

On Wed, 24 Jun 2009 16:08:25 +0200 Joerg Sonnenberger <joerg@britannica.bec.de>
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
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com


------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[prev in list] [next in list] [prev in thread] [next in thread]