On Mon, 2008-05-05 at 23:21 +0100, Richard W.M. Jones wrote:
> On Mon, May 05, 2008 at 09:25:24AM -0400, Neal Becker wrote:
> > Nice, but I think it would be nicer to implement this directly in python
> > (ducks...)
> So we can get all the advantages of consuming huge amounts of memory,
So I've actually had a look at this, recently, mainly due to yum
resource usage on .i386 vs. x86_64 and this troll response to a troll
response is a good a place as any to put it, I think.
So first I wrote a simplish program which just created new
yum.YumBase() objects and appended them to a list (numbers got from
parsing /proc/self/status) which gave me:
...which is about what we've seen when profiling yum itself, 2x for RSS
and much more for VSZ (10x to start with above, which is nice). Then I
added a "pmap" call right at the end, the most interesting bit of which
result = __mmap64 (NULL, mapsize, PROT_READ, MAP_FILE|MAP_COPY, fd, 0);
...which means any locale using C program gets an extra ~73MB of VSZ at
startup on .x86_64. And that any C program gets ~2MB VSZ per. shared
object it loads.
The next interesting bit is that there are roughly 24 "anon" mappings
for .x86_64 and only 20 for .i386, a little investigation shows that
glibc is again the reason as the default M_MMAP_THRESHOLD doesn't expand
with size_t/time_t/etc. ... and setting MALLOC_MMAP_MAX_=0 produces the
same number of anon mappings on x86_64.
At which point the numbers then add up as "simple doubling" as you go
from 4 byte size_t/time_t/intptr_t/etc. to 8 bytes for the same.
 I assume this dead space is for a reason (alignment?), and isn't
wasting any real memory (RSS implies this is true) ... although it is
far from obvious what is happening in both cases.
James Antill -- <email@example.com>
"Please, no. Let's not pull in a dependency for something as simple as a
string library." -- Kristian Høgsberg <firstname.lastname@example.org>
fedora-devel-list mailing list