Oops, I only sent the commit to Carsten in private, didn't CC the ML. :P e2344b9b9ef664c8a251ef21d1afabee0b8326fd
In the EFL is the relevant one. The problem was that a lot of information was written into RW memory pages, so the OS couldn't share those pages across applications, which means memory usage would be much bigger than it should be. This commit fixes this by shifting some things around, and marking the relevant data structures as "const" (read only), so they would be placed in a RO section. I hope that clarifies things. Let me know if you need more info. -- Tom. On Wed, Oct 14, 2015 at 6:29 PM, Amitesh Singh <[email protected]> wrote: > Hello Tom, > > > On Wed, Oct 14, 2015 at 6:41 PM, Tom Hacohen <[email protected]> wrote: > > > On 28/09/15 18:43, Tom Hacohen wrote: > > > >> On 10/07/15 04:27, Carsten Haitzler wrote: > >> > >>> it has come to my attention that we have a bit of a memory bloat issue > >>> with eo. > >>> > >>> and that has to do with eo at runtime doing things like: > >>> > >>> _eo_class_funcs_set() > >>> > >>> read it. loop over all ops int he op desc table (array) foir the class > >>> then go > >>> MODIFYING the array - setting pointers > >>> > >>> op_desc->op = op_id; > >>> + > >>> op_desc->op = api_desc->op; > >>> op_desc->doc = api_desc->doc; > >>> etc. > >>> > >>> now here is the rub. across a LOT of classes, we will have 50, 100+ of > >>> these > >>> arrays. each one will maybe span 1-2 or maybe 3 pages of ram, this is > RW > >>> memory > >>> coming from the lib and every single app goes duplicating this then > >>> modifying > >>> these pointers to be THE SAME THING in each process. > >>> > >>> first problem - the modified bits vs static bits are spread out. thus > we > >>> may > >>> modify only 1 or 2 ptrs per item in the array, but the whole array > spans > >>> a fair > >>> bit of memory and thus... we end up modifying multiple pages of memory > >>> .. per > >>> library etc. - this adds up quickly. maybe 40-80kb per process. then > this > >>> multiples by the number of processes we have using efl. that's costly. > >>> > >>> we need to fix/adjust this so it can/is set up at COMPILE TIME with a > >>> bunch of > >>> consts. eolian needs to take care of this. > >>> > >>> catch - eo allows runtime dynamic overriding of a class. you can > >>> literally > >>> generate it and modify it as you please at runtime based on current > code > >>> paths. > >>> we still would like this to work. so we need to have 2 paths. 1 where > we > >>> pre-fill a class at compile-time all cosnt'd out, then to override at > >>> runtime - > >>> duplicate to non-const version then modify at will. > >>> > >>> the catch here is - to do these fixes will mean breaking eo abi. i'm > >>> looking at > >>> it now and i can't see an alternative there. > >>> > >>> so first - we need to hold off on calling eo stable. then fix this. > this > >>> doesn't stop interfaces work - it just means we have extra to do. > >>> > >>> > >> Finally got around to it. Fixed now. Please take a look and tell me if > >> you see anything bad still. > >> > > > > OK, wow. This has been very annoying. :P > > It's definitely fixed, though for some reason all of my tests to verify > > this have failed until now. Now everything finally shows the correct > > results. More specifically, I can see the improvement in clean vs dirty > > pages when running: pmap -p -XX `pidof elementary_test`. > > I attached the full pmap output from before and after my fix, just an > > example for elementary, private clean and private dirty: > > Clean Dirty > > Before: 0 2336 > > After: 2224 0 > > > > An obvious win. > > > > Thanks again to Carsten for noticing this. This is something that slipped > > in Eo2 (was OK with Eo1) and almost went unnoticed. > > > > This is great. :) and I am sure fixing this had been fun. ;) > I am curious to know how did you fix it? Whenever you get time, please do > list out the relevant commits, so that I can relate things. > I did some reverse engineering before (during college days) so can pick up > this quickly. :) > > -- > > Tom. > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > enlightenment-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
