Gather Arena stats

Jason Evans jasone at canonware.com
Tue Nov 26 16:28:40 PST 2013


On Nov 26, 2013, at 4:20 PM, Eduardo Silva <edsiper at gmail.com> wrote:
> On Tue, Nov 26, 2013 at 2:10 PM, Eduardo Silva <edsiper at gmail.com> wrote:
> On Tue, Nov 26, 2013 at 2:01 PM, Jason Evans <jasone at canonware.com> wrote:
> On Nov 26, 2013, at 11:40 AM, Eduardo Silva <edsiper at gmail.com> wrote:
>> i am interested into gather memory usage per Linux thread, as i am using jemalloc i think this can be done quering the arenas per thread. if i am correct, do you have some code example that accomplish something similar to this ?
> 
> Threads don't own memory; allocated regions can be shared among threads, and allocation/deallocation can be split between threads.  That said, jemalloc does track total volume of allocation and deallocation on a per thread basis, so you can derive the information you want as long as you account for allocated regions that are shared among threads.  Take a look at the "thread.allocated" and "thread.deallocated" mallctl() interfaces in the man page:
> 
> 	http://www.canonware.com/download/jemalloc/jemalloc-latest/doc/jemalloc.html
> 
> There is a relevant test program included with jemalloc:
> 
> 	https://github.com/jemalloc/jemalloc/blob/dev/test/allocated.c
> 
> thanks for your help!, thats the info that i need.
> 
> I have implemented a similar code and its working great. Now an extra question: i would like to spawn a thread to monitor the threads allocation/deallocations, can i access this data from a different thread ?, if so, is there any API or example available ?

You can call the "thread.allocatedp" and "thread.deallocatedp" mallctl() interfaces from each thread you care about, then pass the pointers to your monitoring thread.  You may get stale reads if you read the counters from a different thread since there's no synchronization protecting reads/writes of the counters, but in practice the values you read are unlikely to be substantially out of date, at least on x86/x64 systems.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20131126/50ce6158/attachment.html>


More information about the jemalloc-discuss mailing list