> > 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) ras...@rasterman.com > > =============================================
wow a lot of INFO thanks ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
