Re: Memory statistics

[Lubos Lunak <l lunak suse cz>]

On Tuesday 25 April 2006 19:34, Federico Mena Quintero wrote:
> On Sat, 2006-04-22 at 22:21 +0200, Lubos Lunak wrote:
> >  [*] The fact that it's been in Gentoo since ages doesn't count. It still
> > has a number of practical problems and especially when it gets to memory
> > usage it can't even hold a candle to kdeinit. I should even have some
> > numbers on this in my blog or somewhere (for KDE apps indeed), I could
> > try to dig it up if there'd be interest.
>
> Those numbers would be very interesting to see :)

 Hmm, looks like I can't find any previous ones, so I'll just make new ones. 
Running 'cat /proc/<pid>/smaps | grep Dirty | awk 'BEGIN {cnt=0} {cnt+=$2} 
END { print cnt}'' on the kdeinit process shows here 1208K :(. So that's the 
top limit of how much memory kdeinit saves per process. Out of that 1208K 
only 176K is the heap (128K shared + 48K private).

 Running the same on e.g. kdeinit-launched KCalc shows 2672K total, with 
Private_Dirty 1756K (1564K heap) and Shared_Dirty 916K, which should be the 
savings gained from kdeinit.

 For kdeinit, roughly 0,5M comes just from dirty data.rel.ro sections which 
should correspond to relocations done in vtables and moc tables. If I leave 
out all KDE/Qt libs, the total usage is still at 480K.

> But yeah, even if we get down to 4 KB per library, it still becomes a
> big number when you consider 4 KB * num_libraries * num_processes.
>
> Moving to a forking scheme like kdeinit is probably not too hard.  Are
> there any pitfalls we should watch for?

 I don't remember any, but that doesn't mean anything. The only "problem" is 
that you can't pre-fork that much data. You can't initialize X connection, 
because forking will cause serious trouble with it, the same with any other 
file descriptor, temporary file, shared memory segment, whatever (and I don't 
know about you but initialization of a KDE application is a rather extensive 
process, so this would be difficult to check).

 There's also the issue of whether it's worth it for you. As soon as the 
forked app writes to any shared memory, you get COW immediately and the 
effect is lost. So sharing .got is fine as it's not fragmented and there 
should be no writes afterwards, but e.g. sharing heap is much worse. We also 
gain a lot from sharing vtables and moc tables, but that's only they also are 
in one block of memory and won't be written to afterwards (that's the 
data.rel.ro section, I asked one gcc developer to make gcc group things 
in .data by type). You however shouldn't have much of this either.

 On the other hand you'll have to compile even apps as PIC, which means they 
get all the GOT etc. stuff, one register is taken, it's slightly slower and 
so on. You should probably first at least check if it'd be really worth it 
and if you just don't have a lot of silly things in .data that could be fixed 
in a simpler way. I'd be interested in your numbers too :).

> Can we adapt maemo-launcher for general GNOME use?
>
>   Federico

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/