Re: [Fwd: libpng shared memory patch]

[Lubos Lunak <l lunak suse cz>]

On Sunday 23 April 2006 07:29, Behdad Esfahbod wrote:
> On Sat, 22 Apr 2006, Lubos Lunak wrote:
> > > libpng version 1.2.8rel-5 from dapper
> > >
> > > before:
> > >
> > > $ objdump -x /usr/lib/libpng.so  | grep data
> > >   11 .rodata       00002a00  00021a30  00021a30  00021a30  2**3
> > >  18 .data         00000348  00034cd0  00034cd0  00024cd0  2**2
> > >   20 .sdata        000000b0  0003502c  0003502c  0002502c  2**2
> > >
> > > 0x348+0xb0=0x3F8=1016 bytes
> > >
> > > $ python memstats.py | grep libpng
> > > private: /usr/lib/libpng12.so.0.1.2.8: 168 KB (spread among 84
> > > mappings)
> >
> >  This in other words means that every process has two dirty pages because
> > of libpng.
>
> How did you get two pages?  Each process has two mappings for
> libpng12.  So with 84 mappings, there are 42 processes, and 168
> KB / 42 = 4k = 1 page.

 Oops, I overlooked the KB and thought it was pages (and didn't realize it was 
counting no-writeable mappings too)[*]. If you have only one dirty page per 
process, I'm afraid there's nothing to improve.

[*] I guess that also means that I was wrong on the memstats table from 
Federico's blog. The theoretical maximum possible reduction then should be 
16M->4M instead of 16M->8M.

> Note that even moving from .data to .rodata is desirable anyway,
> even if it doesn't result in reduced memory consumption, it does
> result in reduced relocations which is good.

 The question is if those few relocations are worth the effort.

-- 
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/