proc memory statistics tapset

[Mark Wielaard]

Hi,

I recently added printing of memory usage to each stap pass in verbose
mode to see how much (extra) memory each pass contributed. Which helped
me to keep track of memory usage while I refactored some of the dwfl
construction code.

It occurred to me this is actually what we need to use systemtap for. We
already have markers in stap itself that can be probed for the start and
end of each pass. So instead of adding new source code I should have
added a tapset that provides that information. That way it could be
reused by anybody that wants to trace a program and get memory
measurements/statistics. So that is what I just did.

With this new tapset you get the same results as stap -v (actually a bit
more and nicer human readable memory strings) with this oneliner: 

$ stap -e 'probe process("stap").mark("pass[0-3]*") { log($$name . "\t" . proc_mem_string()) }' -c 'stap -k -p4 testsuite/buildok/context_test.stp'
pass0__start	size: 58m, rss: 2528k, shr: 2068k, txt: 1352k, data: 428k
pass0__end	size: 58m, rss: 2548k, shr: 2088k, txt: 1352k, data: 428k
pass1a__start	size: 58m, rss: 2548k, shr: 2088k, txt: 1352k, data: 428k
pass1b__start	size: 58m, rss: 2748k, shr: 2240k, txt: 1352k, data: 428k
pass1__end	size: 74m, rss: 18m, shr: 2400k, txt: 1352k, data: 16m
pass2__start	size: 74m, rss: 18m, shr: 2400k, txt: 1352k, data: 16m
pass2__end	size: 74m, rss: 19m, shr: 2584k, txt: 1352k, data: 17m
pass3__start	size: 74m, rss: 19m, shr: 2584k, txt: 1352k, data: 17m
pass3__end	size: 74m, rss: 19m, shr: 2784k, txt: 1352k, data: 17m

But it is usable for any probe in any program (or the kernel, as long as
there is an associated current task for the probe point), and you don't
have to print anything, you can also query the different memory stats
individually and put them in an aggregate to show max/min/avg over time,
etc.

I would like to add it as tapset/proc_mem.stp and put the documentation
together with the Memory Tapset in the Tapset Reference manual since I
think they are generally useful. But if people feel they should go into
the examples only, that is fine too.

They are currently all marked /* unprivileged */ since the same
information is world readable through ps, top or /proc/pid/statm. But
the functions could also check is_myproc() and return zero in such
cases.

The code is slightly paranoid when it comes to fetching the mm struct,
but that was the only way I could see that made it safe. It only works
for the current task because that is what we can access lock free. For
any other task we would need to somehow keep some shadow bookkeeping to
prevent having to take locks on task and/or mm structs and I don't think
that is really worth it. The interesting memory stats are probably those
of the current process anyway.

Tested against 2.6.18 and 2.6.31.1 on x86_64 and 2.6.30 on i686, testson
other kernels and architectures or any other feedback very welcome.

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_mem.stp
Type: text/x-csrc
Size: 5810 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20091005/9de5c9ae/attachment.bin>