Relationship between opt.prof and opt.prof_leak

[Evan Jones]

This explanation makes perfect sense, thanks! I'm also assuming that with
prof_accum:true, the stats that are logged are *only* the cumulative stats,
so when you run jeprof that s what you get.

This was extremely helpful, I'm going to try to create a patch for the
jemalloc man page to make it clearer. This is a super, super useful
feature, and I'm not sure why I found the configuration options so
confusing, since I think they are fairly straightforward now that I
understand them.


On Sun, Nov 8, 2015 at 2:35 PM, Jason Evans <jasone at canonware.com> wrote:

> On Nov 6, 2015, at 2:01 PM, Evan Jones <ejones at twitter.com> wrote:
>
> On Fri, Nov 6, 2015 at 4:57 PM, Jason Evans <jasone at canonware.com> wrote:
>
>> On Nov 6, 2015, at 12:53 PM, Evan Jones <ejones at twitter.com> wrote:
>>
>> On Fri, Nov 6, 2015 at 3:45 PM, Jason Evans <jasone at canonware.com> wrote:
>>>
>>> No, dumps are always based on the most recent stats reset (process start
>>> or "prof.reset" mallctl call).  You can view incremental differences
>>> between two dumps by using the --base option to jeprof.
>>>
>>
>> Is this true if you use opt.lg_prof_interval? Then what is the point of
>> the opt.prof_accum option?
>>
>>
>> opt.lg_prof_interval is merely a dump triggering mechanism.
>>  opt.prof_accum controls whether cumulative stats are collected at all.
>>
>
> There must be something stupid that I don't understand then. You said:
> "dumps are always based on the most recent stats reset", which is usually
> the process start time, unless you do some manual reset. Does this mean
> that prof_accum is *only* useful if you do manually trigger resets using
> mallctl("prof.reset")? Does this mean that with prof_accum:true, the dumps
> contain *both* the data since the last reset *and* the data since profiling
> was enabled?
>
>
> Take the following function as an example, run with
> MALLOC_CONF=prof:true,prof_accum:true :
>
> void g(void *p);
>
> void
> f(void) {
> unsigned i;
>
> for (i = 0; i < (1U << 20); i++) {
> void *p = malloc(1U << 30);
> if (i == (1U << 19)) {
> mallctl("prof.dump", NULL, NULL, NULL, 0); /* A */
> mallctl("prof.reset", NULL, NULL, NULL, 0);
> mallctl("prof.dump", NULL, NULL, NULL, 0); /* B */
> }
> if (p != NULL) {
> g(p);
> free(p);
> }
> }
> mallctl("prof.dump", NULL, NULL, NULL, 0); /* C */
> }
>
> What will the heap profiling stats (as interpreted by jeprof) dumped at A,
> B, and C say regarding the malloc() site in f()?
>
> A:
>   - Current: ~1 object, ~2^30 bytes
>   - Cumulative: ~2^19 objects, ~2^49 bytes
> B:
>   - Current: 0 objects, 0 bytes
>   - Cumulative: 0 objects, 0 bytes
> C:
>   - Current: 0 objects, 0 bytes
>   - Cumulative: ~2^19 objects, ~2^49 bytes
>
> opt.prof_accum controls whether jemalloc maintains the cumulative stats.
> With MALLOC_CONF=prof:true,prof_accum:false, you will get no cumulative
> stats at all, no matter when/whether any resets occurred.
>
> Jason
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20151116/a8a1ffc0/attachment.html>