This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: user mode backtrace
David Boreham wrote:
Vara Prasad wrote:
If i read your above message correctly you would like to put probes in
the kernel but you want to get a full stack which includes kernel mode
stack and as well as user mode stack, correct.
ack
David, if you want to put probes in the user space itself and do back
trace we are working on user space probing patch that will let you
see the stack just in the application space only. We may be able to
give some thing for you to play within couple of weeks if you are
interested in user space probing.
I'm not sure if this would work. It depends on whether I would need to
identify the
processes subject to probing in advance. The application spawns
processes left and right,
many of which are sort-lived. If I could place a probe in the glibc
layer above
the system calls that might work, but said probes would need to magically
apply to any process that called that code. Is that the feature you have
in mind ?
But even so, I can imagine cases where it would still be useful to probe
in the
kernel but show user stack : e.g. I probe physical read from disk
because I am
not interested in reads served from filesystem cache. But I'd like to
find out
where the read calls that hit non-cached data are coming from in the
application.
Hope that makes sense.
The disk I/O schedules the reads and writes. It is unlikely that the matching
user process is running when the physical read occurs. Would it be useful to
look at the elapsed time between entry and exit time of the read system call and
trigger recording of information if it is over some threshold?
Would it make sense for the probing code to mark that userstack is needed and
then record when the processor is about to return to userspace? The marking
takes a fixed amount of time to do, so should be safe for probes.
-Will