Bug 3888 - need accumulated memory usage counter
Summary: need accumulated memory usage counter
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: runtime (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Martin Hunt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-18 22:35 UTC by Frank Ch. Eigler
Modified: 2007-01-29 20:46 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2007-01-18 22:35:18 UTC
For purposes of debugging, it would be nice to have exported from
the runtime a number (or a function that returns a number) that
corresponds to the total amount of dynamic kmalloc/vmalloc memory
allocated by the runtime for the probe module.  This should include
the I/O buffers and arrays and any other bulky stuff.

Then, this value should be included in the printk emitted by
the translator's c_unparser::emit_module_init.
Comment 1 Frank Ch. Eigler 2007-01-25 13:52:41 UTC
(In reply to comment #0)
> Then, this value should be included in the printk emitted by
> the translator's c_unparser::emit_module_init.

That printk would need to be moved a few blocks lower, if we
wanted to print the dynamic memory allocation statistics after
global (array) initialization.  But it should still go before
all the potentially problematic probe registration loops.
Comment 2 Martin Hunt 2007-01-25 21:43:40 UTC
Before I check this in, I thought I'd ask what specifically this is for and if
there might be a need for more than just a single number.  Memory is allocated
for 3 different uses (4 if you count code); maps, symbols, and IO buffers. 
Comment 3 Frank Ch. Eigler 2007-01-25 21:49:39 UTC
It's for assisting diagnosis of systemtap-related problems,
such as OOM (!).  I imagine just printing the number.  If you
think it would make sense to have one or two more printed in
that already-long printk, that's OK.
Comment 4 Martin Hunt 2007-01-29 19:26:22 UTC
On further thought, I decided one number wouldn't be helpful.  Here is the
current output. How does this look?

stap_860d715dd802b0abad3ad73414251ad3_6488: systemtap: 0.5.12, base: f8f25000,
memory: 126339+19493 data+text, probes: 2
systemtap: Allocated memory: context: 13184, IO buffers: 2101248, maps and misc:
789633

One subtle change I made to what was already there is that I subtracted the
module core_text_size from the core_size, leaving the data size. I think that
was probably what you wanted when printing the "data+text".

Comment 5 Frank Ch. Eigler 2007-01-29 19:39:33 UTC
(In reply to comment #4)
> On further thought, I decided one number wouldn't be helpful.  Here is the
> current output. How does this look?
> 
> stap_860d715dd802b0abad3ad73414251ad3_6488: systemtap: 0.5.12, base: f8f25000,
> memory: 126339+19493 data+text, probes: 2
> systemtap: Allocated memory: context: 13184, IO buffers: 2101248, maps and misc:
> 789633

I would like it more compact please, to fit it all on one line if possible.
Let's try this one:

stap_860d715dd802b0abad3ad73414251ad3_6488: systemtap: 0.5.12, base: f8f25000,
 memory: 126339+19493+13184+2101248+789633 data+text+ctx+io+glob, probes: 2


> One subtle change I made to what was already there is that I subtracted the
> module core_text_size from the core_size, leaving the data size. I think that
> was probably what you wanted when printing the "data+text".

By "data" I meant total-text, yes, so if core_size includes text too then
subtracting as you say is appropriate.
Comment 6 Martin Hunt 2007-01-29 20:46:31 UTC
Checked fix into CVS.