Threaded 6.4 code compiled under 9.0 uses a lot more memory?..

[Ian Lepore]

On Thu, 2012-11-01 at 10:12 +0800, David Xu wrote:
> On 2012/10/31 22:44, Karl Pielorz wrote:
> >
> >
> > --On 31 October 2012 16:06 +0200 Konstantin Belousov
> > <kostikbel at gmail.com> wrote:
> >
> >> Since you neglected to provide the verbatim output of procstat, nothing
> >> conclusive can be said. Obviously, you can make an investigation on your
> >> own.
> >
> > Sorry - when I ran it this morning the output was several hundred lines
> > - I didn't want to post all of that to the list 99% of the lines are
> > very similar. I can email it you off-list if having the whole lot will
> > help?
> >
> >>> Then there's a bunch of 'large' blocks e.g..
> >>>
> >>>  PID              START                END PRT  RES PRES REF SHD  FL TP
> >>>  PATH 2010        0x801c00000        0x802800000 rw- 2869    0   4   0
> >>> ---- df 2010        0x802800000        0x803400000 rw- 1880    0   1   0
> >>
> >> Most likely, these are malloc arenas.
> >
> > Ok, that's the heaviest usage.
> >
> >>> Then lots of 'little' blocks,
> >>>
> >>> 2010     0x7ffff0161000     0x7ffff0181000 rw-   16    0   1   0 ---D df
> >>
> >> And those are thread stacks.
> >
> > Ok, lots of those (lots of threads going on) - but they're all pretty
> > small.
> >
> Note that libc_r's thread stack is 64K, while libthr has 1M bytes
> per-thread.

That would help explain the large increase in virtual size, but not the
increase in resident size, right?  In other words, there's nothing
inherent in libthr that makes it use more stack, it just allocates more
vmspace to allow greater potential growth?

Hmmm, actually the chunks said to be thread stack above are neither 64K
nor 1M, that's 128K.  The malloc arenas are 12M, which seems like an
unusual value.  I haven't looked inside jemalloc at all, maybe that's
normal.

-- Ian