This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Systemtap caching behavior
Thank you Mark, that did the trick!
One more, perhaps naive question. What I am trying to do is generate fame graphs per http://brendangregg.com/FlameGraphs/cpuflamegraphs.html . At the moment, I have succeeded in making the flame graphs in which the call stacks begin with entry_SYSCALL_64_fastpath. If I wanted to include the user space calls that made these system calls, would my next step be to re-compile the application that we are profiling (the BIND DNS daemon) with one of the gcc debug flags (https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html)?
Is there anything else that I would need to do?
Thank you,
Mike
> On Jan 13, 2019, at 4:58 AM, Mark Wielaard <mark@klomp.org> wrote:
>
> On Sat, Jan 12, 2019 at 07:59:14PM -0500, Mikhail Zhukovskiy wrote:
>> I have a question about systemtap caching behavior.
>>
>> According to the man page, the results of pass 3 and pass 4 (the translation to C and the compilation of the kernel module) should be cached between runs, however this is not what I am observing. Could you please point out what I’m doing wrong?
>> [...]
>> /home/vagrant/systemtapbin/bin/stap -k -s 32 --all-modules -v -D MAXBACKTRACE=100 -D MAXSTRINGLEN=4096 -D MAXMAPENTRIES=10240 -D DMAXACTION_INTERRUPTIBLE=500 -D MAXACTION=100000 -D STP_OVERLOAD_THRESHOLD=5000000000LL flame-kernel.stp > out.stap-stacks
>
> You are using -k:
>
> -k Keep the temporary directory after all processing. This may be
> useful in order to examine the generated C code, or to reuse the
> compiled kernel object.
>
>> Keeping temporary directory "/tmp/stapy6Mjkr"
>
> This bypasses the cache.
>
> Cheers,
>
> Mark