On Sat, 29 Dec 2012 02:43:59 +0300 المسالم المسالمة <[email protected]> said:
> hello again > > take a look at the picture > > as you can see from it .... enlightenment use 725 megabyte from VM > > so is this a normal situation or what ... because i hear E17 is a > light-desktop > > but this result is really shocking you have fallen into the trap of not knowing the difference between virtual memory mappings and real memory. you'll also find that your gl/gpu drivers/libs are prety much responsible for 90% of the memory usage of e if you use compositing and gl. i've spent a lot of time profiling this stuff. different drivers (nvidia vs intel vs fglrx vs nouveau vs radeon vs sgx vs mali etc.) will have vastly different memory footprints. almost all of them allocate insanely huge blobs of memory that i just can't account for in terms of what evas has asked for - like allocating extra software render buffers in addition to the gpu owned video ram blobs for the buffers etc. tand thats in the 75m blob there. actual RESIDENT (used memory). some of that is shared (shared memory segments, video ram blobs, shared libraries, executable code etc. so that memory use used by 1 or more processes anyway - libc for example). some of it is actual needed memory, with virtual memory .... its virtual. it doesnt have to exist. example - the gl drivers may happily mmap() ALL of video memory ino so they can SEE it. they may or may not use it, but they can SEE it. they may map in large chunks of memory that are simple register windows mapped over the pci/agp bus. it's virtual memory - but its actually just hardware control register ranges. this is all done by the opengl library and thus it appears as virtual memory usaage by the process. there is a lot of material on this topic floating about the internet. research it. i highly suggest that anyone, before they make claims on memory usage, gains a firm grasp on all of this virtual vs resident vs shared etc. and know how to read what the kernel is saying, and that you find appropriate methods and tools to actually measure things. just looking at vsize in top/ps is the WORST way to do this. (there is only 1 possible sensible use for it - and that is if you are going to run out of memory SPACE... that's a problem once you need like 1-2gb (in any single continuous mapping) or more on a 32bit architecture. you can get up to 3.5gb or so depending on arch/setup but thats about it in practical terms unless you go to 64bit - but thats just memory address SPACE... not actual used memory). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
