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 > > <kostik...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
