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

[Konstantin Belousov]

On Wed, Oct 31, 2012 at 02:44:05PM +0000, 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?
Just put is somewhere on http server and provide the URL.

> 
> >> 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.
So it is, most likely, either app doing more malloc allocations, or the
difference is due to more aggressive jemalloc behaviour. If this indeed
bothers you, you could try to use plug-in replacements for malloc.
They are usually LD_PRELOAD'ed, search the ports.  But I would not bother.

> 
> >> 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.
> 
> My code only has a single call to malloc, which allocates around 20k per 
> thread.
You should look both at the virtual address space allocation for the block,
which is specified by (start, end), and at the actual resident page count.

> 
> Obviously there's other libraries and stuff running with the code - so 
> would I be correct in guessing that they are more than likely for most of 
> these large blocks?
No idea.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20121031/27c8db87/attachment.sig>