This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Example looking at the periodic timers
- From: Mark Wielaard <mjw at redhat dot com>
- To: William Cohen <wcohen at redhat dot com>
- Cc: systemtap at sourceware dot org
- Date: Wed, 14 Dec 2011 12:23:54 +0100
- Subject: Re: Example looking at the periodic timers
- References: <4EE7CA4E.9080109@redhat.com>
On Tue, 2011-12-13 at 16:57 -0500, William Cohen wrote:
> One case that people would like to use SystemTap for is finding out
> why some latency sensitive application is slowed down every x seconds.
> They know that something keeps running on the machine and slowing
> things down, but they don't know what it is.
>
> I have been playing around with the timer tracepoints and came up with
> the attached script, periodic.stp. When the script exits it prints
> out a list of the periodic timers, sorted from most frequently to
> least frequently fired timer. It also include the average period for
> the timer. The functions that have [dg] are things put into the
> delayed_work_queues.
Looks nice. I would add a begin probe to announce the script started and
that the user must press control-C to get results and/or make the end
probe a end,timer.s(10) probe so that you get output every 10 seconds
(then you can also clean up the tables).
Are the timer addresses really useful? I just don't know how to
interpret them, does it matter on which timer some event fired?
Printing the comms on process_timeout is a nice touch. Maybe explicitly
prefix it with process: or some other string making that more clear?
You could also add modname() to the output, then people can more easily
see whether it is a kernel or module function being triggered.
I also got some functions that don't immediately make sense, they don't
seem to fall inside either the kernel nor a module. Did you figure out
where they point at? From seeing the high address I assume they are
actually dynamically allocated structures, not direct functions.
Cheers,
Mark